UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
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
Re: UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
Scott Kitterman wrote: On Wednesday, December 19, 2012 01:02:21 PM Emmet Hikory wrote: 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. Do the diffs launchpad produces from UDD merge branches not work as an input diff with grab-merge? I've never tried for this specific type of merge, but in cases where it was just a patch being applied to an existing Ubuntu package, I had success pulling diffs from LP to apply. -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
On Wednesday, December 19, 2012 02:02:58 PM Emmet Hikory wrote: Scott Kitterman wrote: On Wednesday, December 19, 2012 01:02:21 PM Emmet Hikory wrote: 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. Do the diffs launchpad produces from UDD merge branches not work as an input diff with grab-merge? I've never tried for this specific type of merge, but in cases where it was just a patch being applied to an existing Ubuntu package, I had success pulling diffs from LP to apply. It's been some time since I tried this, so i don't recall. I don't see how it can beat grab-merge $PACKAGE and an appropriate packaging diff in a bug for simplicity. When I use grab-merge there's everything I need sitting there is a directory ready for me to use. No hunting for diffs or branches needed. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
