On Wednesday, December 19, 2012 01:02:21 PM Emmet Hikory wrote: > 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?
With respect to the last point, similar to your description of your work flow, I want to see the packaging diff including the Debian -> Debian packaging diff, the Ubuntu --> Ubuntu packaging diff and the Debian old/new -- Ubuntu old/new packaging diffs to ensure no Ubuntu changes have been inadvertently lost, the remaining changes are both needed and documents, and the changes from Debian are correctly applied. i end up needing then the old Debian and Ubuntu packages as well as the new Debian package and the proposed merged. There's probably some reasonable way for me to extract all that from some relevant branches somewhere, but to me it's far easier to use grab-merge and a debdiff. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
