contributions

[Scott Kitterman]

On Tuesday 13 May 2008 22:31, Emmet Hikory wrote:
> Scott Kitterman wrote:
> > On Wed, 14 May 2008 08:11:43 +0900 "Emmet Hikory" wrote:
> >  >    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.
>
>     My personal common methods are tracking the output of
> multidistrotools or reviewing the packages.qa.debian.org output for
> selected packages (although I do occasionally also use MoM).  I'm
> usually more interested in clusters of things, or classes of efforts
> than specific packages, which may be part of that.

OK.  Fair enough.

> >  >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.
>
>     While I don't disagree with this, I don't see how this is an
> argument for checking with the previous uploader vs. checking for a
> filed bug vs. checking for a comment in some location.  It's just a
> matter of there being some official place where all merge efforts are
> tracked, and common agreement that all people working on merges will
> keep that resource updated.  Given that a number of the people also
> working on Debian belong to various collaborative maintenance teams, I
> would not expect it to be a rare case where the last uploader would
> not be the person working on the Debian package, even when a sync is
> expected.

People who are more familiar with (e.g. touched recently) the package are more 
likely to know this stuff.

> >  >    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.
>
>     OK.  Let me restate it then, as "Any potential merger should check
> all outstanding bugs prior to processing a merge".  If this step is
> expected, it seems least invasive to file a bug if there is none,
> rather than tracking some separate resource when one wants to process
> a merge.  Further, a LP-oriented workflow supports those developers
> who are focused on bugfixes, rather than merges, as they will be
> notified when someone else is processing a merge, and may want to
> collaborate to generate the next revision.  At least speaking for
> myself, I'm much more likely to consider processing a merge when I am
> otherwise working on a package (review the bug, check is there is a
> Debian update, check for upstream code, prepare a patch, prepare a
> revision (which may be a merge), upload).  This may be different for
> those focused on merges as a goal, but I'm not convinced that merges
> for the sake of merging is inherently a good thing (although it may be
> the best current practice to ensure that improvements in Debian are
> available in Ubuntu).

I think they are two separate, but related goals:

1.  Keep Ubuntu in sync with Debian (as much as is feasible) and gain benifits 
of Debian updates/fixes and overall synergy from being a downstream distro.

2.  Fix specific problems in Ubuntu.

Often #1 will accomplish #2 and also often one can mix the two together.

> Morten Kjeldgaard wrote:
> > Another possibility is to let MoM file the merging bugs as the merges
> > are processed. I can't overview the consequences of this, though.
>
>     Assuming the continuation of workflow bugs (see separate
> discussion in ubuntu-bugs), this seems a sensible solution to me.
> When MoM discovers a merge candidate, that is filed as a bug.  When
> someone wishes to work on it, the bug is assigned.  If the merge isn't
> useful, the bug can be given a won't fix status for a task in the
> current development release.

Given there are no alternatives to workflow bugs offerred, I don't think that 
one person's opinion is going to make them go away.  The ubuntu-bugs position 
seems to me to be that it's to inconvenient for them to actually worry about 
disrupting development efforts and so we can just lump it.  We had an 
agreement about some changes to make things clearer and they were unlaterally 
dumped.

>     Note that any implementation ought track the status of bugs filed,
> and only report a new bug for a new Debian update in the case where
> the previous bug has been closed as "Fix Released": any other update
> ought just update / retitle the existing bug (and perhaps reset the
> status).  Any potential implementation of this ought be drafted as a
> blueprint, and receive wide discussion within both the development and
> quality assurance communities to ensure that it will not be
> disruptive.

I'll be glad to be as worried about disruptiont to the QA community as they 
appear to be worried about disruption to my work.

Scott K