contributions

[Emmet Hikory]

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.

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

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

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.

    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.

-- 
Emmet HIKORY