contributions

[Emmet Hikory]

Scott Kitterman wrote:
>  On Tuesday 13 May 2008 22:31, Emmet Hikory wrote:
>  >     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.

    Certainly, although these individuals may not be available at any
given time, hence the continued discussion regarding notification vs.
personal contact.  Neither is ideal, and any solution is at best a
compromise.  For the case where one must claim merges, it adds burden
to those who care about a package who must claim a merge or have
someone else do it.  For the case where one must request permission
for a merge, it adds burden to those with time and inclination to
process merges, as the appropriate counterparty may not be available
(and may never become available, depending on their level of
involvement).  Unfortunately, any solution that is not strictly one or
the other of these is prone to confusion (especially so when someone
uploads a candidate without having either checked for an outstanding
merge notice nor with the last uploader, as apparently started this
discussion).  The primary reason for my preference for a notification
solution is that it rewards people who act, rather than rewarding
those who may have acted in the past, and may contribute to a faster
pace of updates and development.  On the other hand, even in the
presence of a notification system, I'd expect collaboration: with a
"file bug in LP" model, if someone starts on a merge of a package
which I know to be complex, and about which I am likely to have
significant information, I will receive bugmail about the merge
(because I am subscribed to bugmail for the package), and may share
information about the merge to either assist or dissuade them from
continuing (depending on the specifics of the package).

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

    Perhaps.  I see different goals, being:

1. Fix as many issues as can be discovered in Ubuntu (or inferred to
be present in Ubuntu due to existence upstream).

2. Ensure that any Ubuntu-specific bugfixes are passed upstream as far
as they remain applicable in order to free upstream developers to
focus on yet unsolved issues.

    Within this context, a merge is simply a convenient way to package
a selection of fixes from upstream as part of goal #1, and often a
convenient point to review the outstanding patches to verify that
those not Ubuntu-specific have indeed been forwarded upstream for
review and inclusion.

    Note that there is an implicit assumption above that "upstream"
includes Debian, and as such it is often best to have similarity of
packaging towards reducing the number of outstanding bugs and ease
adoption of upstream fixes.

-- 
Emmet HIKORY