RFC: https://wiki.ubuntu.com/UbuntuDevelopment/Merging (Was: Re: WANTED: Merging Recipe!)

Emmet Hikory emmet.hikory at gmail.com
Thu Nov 22 14:45:16 GMT 2007


On Nov 22, 2007 10:48 PM, Morten Kjeldgaard wrote:
> > There is also http://dad.dunnewind.net/universe.php which, while unofficial,
> > has the advantage of having comments so people can give status of what's
> > going on.
> >
> Which actually illustrates my point: there's dad and mom and revu and
> wiki and launchpad and a number of other ad hoc services only known to
> the especially initiated  developers and some which duplicate functions
> of others.

Just a quick glossary for those who are confused:

MoM: The official Ubuntu merge list

    This lists outstanding packages where there has been a Debian
upload since the last Ubuntu upload.  These packages may need a merge,
or a sync, or not need anything at all, depending on the point in the
Ubuntu development cycle, the nature of the changes in Debian, and the
opinion of interested developers.  Some packages are blacklisted as
they are not appropriate to merge or sync from Debian.  Nothing listed
here is a requirement for action, except as controlled by other
policies and procedures, and this site need not be part of any
developers workflow, so long as all other guidelines are met.

DaD:  A community developed alternative to MoM with a nicer interface

    This was built as a possible replacement for MoM during an
extended service outage, and has a nicer interface, although it does
not support a blacklist.  As MoM is part of a larger distributed
infrastructure, is it not atomically replaceable.  Since the
resolution of the service outage, there have been various discussions
as to how best merge the systems, as it is admittedly confusing.

REVU: A community developed package review site

    This site supports the review of community packaged new software
that may be suitable for Ubuntu (or other .deb based distributions,
but primarily Ubuntu).  This should only be used for new software, and
is not suitable as a repository for bugfix uploads or similar
materials.

Ubuntu Wiki:

    This wiki is used to track specifications, instructions, policies,
procedures, and other information of interest to the Ubuntu community.
 This is not used to track bugs, or specific package management
(although there may still be historic remainders from previous use for
these purposes).

Malone (Bug tracking component of launchpad):
    This is used as the main issue and task tracking system for Ubuntu
development.  Anything in malone is potentionally actionable by
someone (although sometimes the action consists of indicating that the
requested change will not be done).  For merges & syncs, once an
investigation has been performed, a bug may be generated if the person
invesitgating it is unable to perform the required action themselves.
For new packages, bugs are often generated by users who do not have
sufficient packaging skills to provide the package directly.  Bugs
have lots of other uses as well.

Other Services:
    Most of the remainder of services of which I am aware are various
QA tools, some more important than others.  I believe that a full list
of those that are updated regularly has been consolidated at
http://qa.ubuntuwire.com/, although I am certain that there are others
under construction.

> Even though I am not a great fan of LP, it would make sense to transfer
> the task of at least some of the "ad-hoc sites" to there. For example,
> when generating the list of packages that need merging, it should *in
> principle* be possible to report these *automatically* as "Please-merge"
> bugs in LP, so the workflow could pivot around that. That would get rid
> of mom and dad for starters.

    I'd be opposed to this.  For some of the packages I watch, I tend
to try to get the changes into Debian first, especially prior to
DebianImportFreeze.  Having autocreated bugs that I needed to keep
updated whilst working through possibly two Debian reivisions prior to
requesting a sync would singificantly increase my workflow (and would
do so even did I not have commit access to the archives).  Further,
MoM (and DaD) provide significant additional information, including an
attempt to perform the merge programatically: neither is currently
good enough to be allowed to upload without human review, but both are
acceptable for some classes of merge.

>  I realize that the workflow has probably evolved slowly along with the
> MOTU population, but take this as a "fresh look" at the process. It
> needs to be revised IMHO.

    I'd argue that it's more a matter of documentation than a
requirement for revision.  With the exception of MoM/Dad (which do the
same thing, and are usually in sync), each service has a distinct
role, with little overlap.  MoM and DaD draw data from substantially
the same sources, and so are typically in sync, such that if an issue
is addressed in one, the other will reflect the work without developer
action.  I'd be more than happy to draft significant expansion of the
above somewhere, if a suitable location could be agreed upon,
Further, I'd be interested to hear if there are either other sevices
not listed above, or additional alternative services indicated as
appropriate for use from other sources.

-- 
Emmet HIKORY



More information about the Ubuntu-motu mailing list