UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)

[Emmet Hikory]

Steve Langasek wrote:
> On Tue, Dec 18, 2012 at 09:33:18PM -0500, Scott Kitterman wrote:
> > It only works better if you are using UDD.  I agree that if your primary
> > workflow is UDD based, then UDD branches are better.  If I get a branch
> > it's as useless for me as a debdiff is for you.  When asked to sponsor
> > things that have a branch, I generally decline or ask for a debdiff.
> 
> Your decision to boycott UDD doesn't make a UDD branch "useless".  A debdiff
> for a merge of a new upstream package version actually *is* useless and is a
> waste of the sponsoree's time, for the stated reason that the "review" of
> such a debdiff involves re-doing the merge myself.

    This exchange leaves me even further confused about how UDD works, but
reviewing merges for new upstream sources has always been a bit fussy, and
while interdiffs of diff.gz worked reasonably for format:1.0 packages, there
is no useful equivalent for format:3.0 packages.

     When I'm attempting to review someone else's merge, I generally want
them to send me enough information that I can produce their candidate
artifacts locally for upload, and generally want to do so in a way that
reduces the opportunity for them to submit files that don't match history
(either previously in Ubuntu or in Debian).  My review tends to consist of
looking at the prior Ubuntu-only changes, looking at the upstream changes,
looking at any changes beyond the new upstream version from Debian, and
ensuring that the resulting artifacts contain the best possible blend of
all of these (possibly combined with fixes for other outstanding bugs
found in Ubuntu).

    With a non-UDD workflow, this involves getting the outstanding Ubuntu
diff (patches.ubuntu.com or merges.ubuntu.com have them if one doesn't want
to download source artifacts and run locally), getting the Debian diff
(also available from merges.ubuntu.com), and some artifact diff (which
could be that presented for sponsoring, although I tend to generate local
artifacts and regenerate the diff).  If I want to separate distribution
changes and upstream changes, filterdiff can help, or I can run diffs only
against contents of debian.tar.gz (or other selected artifacts).

    With a UDD workflow, this involves getting the candidate branch,
reviewing the history to confirm it inherits from preexisting UDD branches,
and then using bzr to generate the same set of diffs, for the same level of
manual consideration.  There are no shortcut pre-generated diffs I can
download, but the bzr branch contains everything so there is no need to
pull from multiple sources: depending on one's local environment this
may be either good or bad in terms of total bandwidth and processing
requirements (and one can convince launchpad to generate the diffs, if
one is sufficiently motivated and lacks local processing facilities).

    In either case, once I have a local artifact, unless I'm dealing with
a package that is handled by some team that doesn't like it, I can just
upload.  When I'm dealing with packages where teams want special things
done, regardless of which solution I choose above, I need to go fiddle
with their special VCS arrangements or get complained at later.

    Now, it may be that in one of my summaries above, I've mischaracterised
one of the workflows, and if so I'd very much like to read an expansion of
both procedures by someone who has a very strong preference for one or another
workflow based on what they consider to be the user experience.  On the other
hand, if I've not mischaracterised it, how can *either* the branch or the
necessary diff to generate candidate artifacts be useless?  While I don't
personally see any benefit of one over the other except in terms of access
speed to review materials (which depends on sufficient local factors that
it isn't likely to be generally applicable), I don't understand how I would
have to redo the merge in either case, how I would be able to perform
the necessary level of scrutiny of the candidate without reviewing the same
set of diffs (ubuntu-to-common-ancestor, debian-to-common-ancestor,
candidate-to-debian, new-upstream-to-old-upstream), nor why I would need
to perform any file editing or reconcillation as part of this review.

    Is it not the case that if one prefers UDD, one can just pull the
current Debian import from launchpad, apply the diff proposed by the
candidate, run debcommit, and end up with a branch with all the same
characteristics as if a branch had been submitted for merging?  Similarly,
is it not the case that if someone submits a branch, one can ask launchpad
to generate the diff, and use that as the merge artifact in a non-UDD
workflow?

-- 
Emmet HIKORY