FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-13-2008, 12:51 AM
"Nicolas Valcarcel"
 
Default contributions

Hi,
*** Since hardy i have notice that some times contributions are not taking into account, mostly on merges. For MOTUs and core devels is not needed to file a bug since it's only needed to upload the package, but some times, a contributor, which need to file a bug, upload his debdiff and ask for sponsorship, make the work for nothing, becase one developer (no one in special) work on that merge and upload it. I think is not fair, and discourage for new contributor, so i think it lack for a common process where this things doesn't happen.

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-13-2008, 07:43 AM
Mathias Gug
 
Default contributions

Hi Nicolas,

On Mon, May 12, 2008 at 07:51:47PM -0500, Nicolas Valcarcel wrote:
> Hi,
> Since hardy i have notice that some times contributions are not taking
> into account, mostly on merges. For MOTUs and core devels is not needed to
> file a bug since it's only needed to upload the package, but some times, a
> contributor, which need to file a bug, upload his debdiff and ask for
> sponsorship, make the work for nothing, becase one developer (no one in
> special) work on that merge and upload it. I think is not fair, and
> discourage for new contributor, so i think it lack for a common process
> where this things doesn't happen.

Are you referring to the fact that the package doesn't show up in the
contributor package list ? Usually the contributor is credited in the
Changelog entry.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-13-2008, 01:18 PM
Scott Kitterman
 
Default contributions

On Monday 12 May 2008 20:51, Nicolas Valcarcel wrote:
> Hi,
> Since hardy i have notice that some times contributions are not taking
> into account, mostly on merges. For MOTUs and core devels is not needed to
> file a bug since it's only needed to upload the package, but some times, a
> contributor, which need to file a bug, upload his debdiff and ask for
> sponsorship, make the work for nothing, becase one developer (no one in
> special) work on that merge and upload it. I think is not fair, and
> discourage for new contributor, so i think it lack for a common process
> where this things doesn't happen.

I appreciate your problem. I remember such things happening in the past too.
It's unfortunate when such things happen, but I don't know what can be done
to prevent it completely. MOTU are supposed to check bugs when they do a
merge.

Ideally we'll have the new merged (pun intended) MoM and DaD up soon so there
is one place to go for merge information that can include comments about what
people are working on. That should help too.

From our IRC discussion, I gather you had discussed the merge with the
previous uploader, but that the MOTU that uploaded his own merge (apparently)
did not. While there is no rule requiring people to check with the last
uploader, I still think it is generally a good idea (particularly early in
the release cycle when there is no great rush to get merges uploaded). That
might have avoided the problem in this case.

I think we have sufficient process in place (MOTU should check bugs before
uploading a merge to see if there are other fixes that should be included) or
coming (single source of merge information with comments) to minimize this
problem. I don't think we'll ever eliminate it completely.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-13-2008, 09:22 PM
"Nicolas Valcarcel"
 
Default contributions

I think i haven't explain myself as i should. The thing was that: developer A uploaded a package on the past release circle, then a merge was publiched on MoM, a contributor take the merge, work on it and upload the debdiff to launchpad reporting the bug as it needs to be, the developer A commented on that bug report, so we can be sure that he knows about the contributor working on that merge, then developer B work on that merge and upload it by himself without noticing the bug report and contributor's work.

That, on the side of the contributor, being a new one, is a really bad thing because he wanted to be his work on the repos, but not only it isn't there, it has been done and uploaded*by someone else.
DaD's comments were a good feature to avoid such things, if contributor left a comment in there, the developer B could see it and work on another merge.


On Tue, May 13, 2008 at 8:18 AM, Scott Kitterman <ubuntu@kitterman.com> wrote:




On Monday 12 May 2008 20:51, Nicolas Valcarcel wrote:
> Hi,
> * * Since hardy i have notice that some times contributions are not taking
> into account, mostly on merges. For MOTUs and core devels is not needed to

> file a bug since it's only needed to upload the package, but some times, a
> contributor, which need to file a bug, upload his debdiff and ask for
> sponsorship, make the work for nothing, becase one developer (no one in

> special) work on that merge and upload it. I think is not fair, and
> discourage for new contributor, so i think it lack for a common process
> where this things doesn't happen.

I appreciate your problem. *I remember such things happening in the past too.

It's unfortunate when such things happen, but I don't know what can be done
to prevent it completely. *MOTU are supposed to check bugs when they do a
merge.

Ideally we'll have the new merged (pun intended) MoM and DaD up soon so there

is one place to go for merge information that can include comments about what
people are working on. *That should help too.

From our IRC discussion, I gather you had discussed the merge with the
previous uploader, but that the MOTU that uploaded his own merge (apparently)

did not. *While there is no rule requiring people to check with the last
uploader, I still think it is generally a good idea (particularly early in
the release cycle when there is no great rush to get merges uploaded). *That

might have avoided the problem in this case.

I think we have sufficient process in place (MOTU should check bugs before
uploading a merge to see if there are other fixes that should be included) or
coming (single source of merge information with comments) to minimize this

problem. *I don't think we'll ever eliminate it completely.

Scott K




--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu



--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-13-2008, 09:48 PM
Scott Kitterman
 
Default contributions

On Tuesday 13 May 2008 17:22, Nicolas Valcarcel wrote:
> I think i haven't explain myself as i should. The thing was that: developer
> A uploaded a package on the past release circle, then a merge was publiched
> on MoM, a contributor take the merge, work on it and upload the debdiff to
> launchpad reporting the bug as it needs to be, the developer A commented on
> that bug report, so we can be sure that he knows about the contributor
> working on that merge, then developer B work on that merge and upload it by
> himself without noticing the bug report and contributor's work.
> That, on the side of the contributor, being a new one, is a really bad
> thing because he wanted to be his work on the repos, but not only it isn't
> there, it has been done and uploaded by someone else.
> DaD's comments were a good feature to avoid such things, if contributor
> left a comment in there, the developer B could see it and work on another
> merge.
>
I think I got that and agree it's unfortunate. The contributor certainly has
my sympathy. I completely get the frustration. I just don't know what can
be done that isn't already planned.

A strict check with the last uploader rule would likely have solved this, but
the community rejected that approach last time it was discussed.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-13-2008, 10:11 PM
"Jordan Mantha"
 
Default contributions

On Tue, May 13, 2008 at 2:48 PM, Scott Kitterman <ubuntu@kitterman.com> wrote:

On Tuesday 13 May 2008 17:22, Nicolas Valcarcel wrote:

> I think i haven't explain myself as i should. The thing was that: developer

> A uploaded a package on the past release circle, then a merge was publiched

> on MoM, a contributor take the merge, work on it and upload the debdiff to

> launchpad reporting the bug as it needs to be, the developer A commented on

> that bug report, so we can be sure that he knows about the contributor

> working on that merge, then developer B work on that merge and upload it by

> himself without noticing the bug report and contributor's work.

> That, on the side of the contributor, being a new one, is a really bad

> thing because he wanted to be his work on the repos, but not only it isn't

> there, it has been done and uploaded by someone else.

> DaD's comments were a good feature to avoid such things, if contributor

> left a comment in there, the developer B could see it and work on another

> merge.

>

I think I got that and agree it's unfortunate. *The contributor certainly has

my sympathy. *I completely get the frustration. *I just don't know what can

be done that isn't already planned.



A strict check with the last uploader rule would likely have solved this, but

the community rejected that approach last time it was discussed.




I too agree that it's unfortunate. However, I don't think it's something people should be getting too upset about (people make mistakes) and I don't think ping-last-uploader is a proper solution to the issue, for various reasons.


My feeling is that the best way to help make sure this kind of thing doesn't happen is to have *one*, canonical place to track merges. Launchpad bugs seems to be the best way we have of doing that currently. Basically, file a merge bug if you're going to be working on a merge and *all* people working on merges, including MOTU sponsors, should be looking *first* to see if somebody has already filed a bug before working on it.


-Jordan

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-13-2008, 10:26 PM
Scott Kitterman
 
Default contributions

On Tuesday 13 May 2008 18:11, Jordan Mantha wrote:

> My feeling is that the best way to help make sure this kind of thing
> doesn't happen is to have *one*, canonical place to track merges. Launchpad
> bugs seems to be the best way we have of doing that currently. Basically,
> file a merge bug if you're going to be working on a merge and *all* people
> working on merges, including MOTU sponsors, should be looking *first* to
> see if somebody has already filed a bug before working on it.

Personally I'd find a file a bug first rule very demotivating. One more rule
to convince me to spend my time on other things.


Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-13-2008, 10:42 PM
"Jordan Mantha"
 
Default contributions

On Tue, May 13, 2008 at 3:26 PM, Scott Kitterman <ubuntu@kitterman.com> wrote:

On Tuesday 13 May 2008 18:11, Jordan Mantha wrote:



> My feeling is that the best way to help make sure this kind of thing

> doesn't happen is to have *one*, canonical place to track merges. Launchpad

> bugs seems to be the best way we have of doing that currently. Basically,

> file a merge bug if you're going to be working on a merge and *all* people

> working on merges, including MOTU sponsors, should be looking *first* to

> see if somebody has already filed a bug before working on it.



Personally I'd find a file a bug first rule very demotivating. *One more rule

to convince me to spend my time on other things.
Contributors already have to file a bug so I figured it'd be easiest for them. A comment on MoM (when that works) would also suffice, IMO. The point being, people need a place to check to see if somebody else is working on a merge and people *especially* need to be checking.


-Jordan

P.S. The idea of me having to wait for somebody else's OK just to do a merge, even though I'm a MOTU/Core Dev, is very demotivating.

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-13-2008, 11:00 PM
Scott Kitterman
 
Default contributions

On Tue, 13 May 2008 15:42:12 -0700 "Jordan Mantha" <mantha@ubuntu.com>
wrote:
>
>
>On Tue, May 13, 2008 at 3:26 PM, Scott Kitterman <ubuntu@kitterman.com>
wrote:
>
>On Tuesday 13 May 2008 18:11, Jordan Mantha wrote:
>
>> My feeling is that the best way to help make sure this kind of thing
>> doesn't happen is to have *one*, canonical place to track merges.
Launchpad
>> bugs seems to be the best way we have of doing that currently. Basically,
>> file a merge bug if you're going to be working on a merge and *all*
people
>> working on merges, including MOTU sponsors, should be looking *first* to
>> see if somebody has already filed a bug before working on it.
>
>Personally I'd find a file a bug first rule very demotivating. One more
rule
>to convince me to spend my time on other things.
>
>
>Contributors already have to file a bug so I figured it'd be easiest for
them. A comment on MoM (when that works) would also suffice, IMO. The point
being, people need a place to check to see if somebody else is working on a
merge and people *especially* need to be checking.
>
>-Jordan
>
>P.S. The idea of me having to wait for somebody else's OK just to do a
merge, even though I'm a MOTU/Core Dev, is very demotivating.

Sure. I can understand that. There is no single solution that will
satisfy everyone. I think checking the comment on DaD (and then MoM once
it's updated) is the best middle ground.

I'm perfectly fine with there being no strict rule about checking as long
as people are sensible/polite about it. If it's a package I've touched 7
of the last 8 times then maybe I have a special interest in the package and
it would be polite to check. OTOH if it's not a tricky merge and it's
blocking your work, I can see not waiting. It would be impolite of me to
want to cause you inconvenience by insting you wait.

It's really just a matter of trying to work together in a complimentary and
collegial manner.

That said, back to the original problem, it is important to check for bugs
and whoever stepped on the contributor's merge shouldn't have done that.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-13-2008, 11:11 PM
"Emmet Hikory"
 
Default contributions

Scott Kitterman wrote:
> On Tuesday 13 May 2008 18:11, Jordan Mantha wrote:
> > My feeling is that the best way to help make sure this kind of thing
> > doesn't happen is to have *one*, canonical place to track merges. Launchpad
> > bugs seems to be the best way we have of doing that currently. Basically,
> > file a merge bug if you're going to be working on a merge and *all* people
> > working on merges, including MOTU sponsors, should be looking *first* to
> > see if somebody has already filed a bug before working on it.
>
> Personally I'd find a file a bug first rule very demotivating. One more rule
> to convince me to spend my time on other things.

While I can understand the "file a bug first" rule to be
demotivating, I'm inclined to agree with Jordan that waiting to hear
from someone who is marginally active can also be demotivating. In
essence, anything that blocks the immediate gratification of wanting
something updated and updating it will be demotivating to someone
(including MoM comments: some mergers don't use MoM). This is further
complicated for those cases where people are involved in Debian and
see merge requests as needing an update in Debian, which might be
waiting for sponsorship at the time someone else wants to process a
merge, but would later be a sync.

That said, I'm a big fan of the "file a bug first" rule, as it
provides the corresponding "check the outstanding bugs first" rule.
It's this latter rule that I think is more important, as many packages
don't get comprehensive bug triage, and would benefit from periodic
review of the outstanding issues. Further, it may be that some of
these issues are resolved by the merge, and that others can be
resolved easily at the same time. By encouraging anyone processing a
merge to review the outstanding bug list against the package at the
time of merge, there is an increased likelihood that other useful
fixes will be done to the package, and that the package will be in a
known good state at the end of the merge, rather than just having had
the previous changes copied blindly.

--
Emmet HIKORY

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 

Thread Tools




All times are GMT. The time now is 03:26 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org