contributions

[Scott Kitterman]

On Wed, 14 May 2008 08:11:43 +0900 "Emmet Hikory" <persia at ubuntu.com> wrote:
>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

I'm not sure how one finds out a merge is needed otherwise (I'm assuming 
MoM/DaD get merged reasonably quickly).  I think a coment field on a page 
you need is about the lowest impact we can get.

>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.

Excellent example of a case where checking is a good idea.

>    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.

Not really.  I find I file a lot bugs via email now.  I think the two are 
not nearly as related as they once were.  Additionally, I'm strongly 
opposed to adding process steps and work on the theory that if we make MOTU 
do B then they'll have to do A they were supposed to do all along.

>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

Agreed.

>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.

Agreed, but I don't think forcing me to write an email to Launchpad 
furthers that goal.

Scott K