Re: Feedback on merging via bzr
On Thu, 28 Jan 2010 09:38:20 -0500 (EST), Scott Kitterman ubu...@kitterman.com wrote: Then maybe the description of what is happening just needs to be improved because as I said in the bug, it sure appears to be looking upstream and getting the tarball from there before it checks Debian. I understand the theory, it isn't clear to me that's what's happening. Both of you are correct. pristine-tar is supposed to make the problems go away, but it isn't perfect. When it doesn't work bzr-builddeb will try some other methods to grab the tarball, but I didn't think to try Debian explicitly (if you have deb-src lines for debian in your sources.list it should work). I intend to add this feature when I get a little time, or I would happily help someone else add it. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Do, Jan 28, 2010 at 11:55:07 (CET), Dmitrijs Ledkovs wrote: On 28 January 2010 10:09, Reinhard Tartler siret...@ubuntu.com wrote: On Do, Jan 28, 2010 at 11:01:37 (CET), Dmitrijs Ledkovs wrote: it would be great if grab-merge could additionally - check the freshness of the import branches - download the orig.tar.gz/orig.tar.bz2 files from debian The branches are pristine-tar enabled you can just $ bzr bd them and a tarball will appear in your tarball's directory. I expected that as well, but it didn't work with the xine-lib package. I think it's a bug. Was it you who added .bzr-builddeb folder with Native config? That's interesting: obviously the debian import is faulty: in the source pacakge published at http://ftp.debian.org/debian/pool/main/x/xine-lib/xine-lib_1.1.17-1.dsc, there is no .bzr-builddeb/default.conf, but in lp:debian/xine-lib is. I remember that I did play around with bzr on the xine-lib package, but I abandoned this idea. For this reason it was removed from debian. This indeed looks like a bug. That's documented already in the Distributed Development wiki. See tips section [1] which requires developers to open up yet another tool. Having the documentation at hand improves the workflow espc. when the wiki is down or you don't have a decently fast internet connection. Fair enough =) then it should probably live in the bzr builddeb plugin as one of the help topics. Cause you need it to work UDD style with packages anyway ;-) indeed -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Do, Jan 28, 2010 at 11:01:37 (CET), Dmitrijs Ledkovs wrote: it would be great if grab-merge could additionally - check the freshness of the import branches - download the orig.tar.gz/orig.tar.bz2 files from debian The branches are pristine-tar enabled you can just $ bzr bd them and a tarball will appear in your tarball's directory. I expected that as well, but it didn't work with the xine-lib package. Perhaps bzr help grab-merge should give recipes for the common diffs that we want instead of actually generating them? Yes, that would espc. help people less familiar with bzr. That's documented already in the Distributed Development wiki. See tips section [1] which requires developers to open up yet another tool. Having the documentation at hand improves the workflow espc. when the wiki is down or you don't have a decently fast internet connection. I did a similar script which just creates a bunch of shared repos and pulls debian ubuntu branches [2] It doesn't attempt to merge it's just there to grab a few merges in one go. Sounds interesting, I'll have a look. To be fair the UDD wiki needs some love from people who used bzr for development. indeed. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On 28 January 2010 06:14, Reinhard Tartler siret...@ubuntu.com wrote: On Do, Jan 28, 2010 at 00:06:52 (CET), Andrew SB wrote: On Sun, Jan 24, 2010 at 9:21 PM, James Westby jw+deb...@jameswestby.net wrote: I would love to have something more akin to grab-merge, and again I would be happy to help someone work on this. I would suggest it get added to bzr-builddeb as that will make some things easier. Here's a quick attempt: https://code.edge.launchpad.net/~andrewsomething/bzr-builddeb/bzr-grab-merge Purpose: Grab packaging branchs for merging. Usage: bzr grab-merge PACKAGE Description: This initiates a shared repository and then grabs both lp:ubuntu/package and lp:debian/package. Next, these branches are merged in ./package/working_tree. Mostly I'm hoping that the ugliness of my code (I'm really just a packaging monkey) will scare someone who knows better into stepping up. =) I didn't implement any changelog handling as that seems to be in-progress elsewhere. I suppose the real question here is exactly what features we want this to have. Do we want to generate diffs like the current grab-merge? Do we feel the need to write a REPORT-like file locally? I think a 'bzr st -rbranch:../debian' and 'bzr st -rbranch:../ubuntu' would be indeed interesting to have in REPORT. it would be great if grab-merge could additionally - check the freshness of the import branches - download the orig.tar.gz/orig.tar.bz2 files from debian The branches are pristine-tar enabled you can just $ bzr bd them and a tarball will appear in your tarball's directory. Perhaps bzr help grab-merge should give recipes for the common diffs that we want instead of actually generating them? Yes, that would espc. help people less familiar with bzr. That's documented already in the Distributed Development wiki. See tips section [1] I did a similar script which just creates a bunch of shared repos and pulls debian ubuntu branches [2] It doesn't attempt to merge it's just there to grab a few merges in one go. To be fair the UDD wiki needs some love from people who used bzr for development. [1] https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging [2] http://people.ubuntuwire.org/~lucas/grab-branches.sh -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On 28 January 2010 10:09, Reinhard Tartler siret...@ubuntu.com wrote: On Do, Jan 28, 2010 at 11:01:37 (CET), Dmitrijs Ledkovs wrote: it would be great if grab-merge could additionally - check the freshness of the import branches - download the orig.tar.gz/orig.tar.bz2 files from debian The branches are pristine-tar enabled you can just $ bzr bd them and a tarball will appear in your tarball's directory. I expected that as well, but it didn't work with the xine-lib package. I think it's a bug. Was it you who added .bzr-builddeb folder with Native config? IMHO that shouldn't be in there. And for example revision 36 of the lp:ubuntu/xine-lib reconstructs original tarball just fine and builds fine. You can try $bzr bd -r36 lp:ubuntu/xine-lib At some point branch got the .bzr-builddeb folder with native package option. Since then the orig-tarballs where not imported using pristine-tar. Investigate further and file a bug against bzr-builddeb or udd porojects on launchpad. Perhaps bzr help grab-merge should give recipes for the common diffs that we want instead of actually generating them? Yes, that would espc. help people less familiar with bzr. That's documented already in the Distributed Development wiki. See tips section [1] which requires developers to open up yet another tool. Having the documentation at hand improves the workflow espc. when the wiki is down or you don't have a decently fast internet connection. Fair enough =) then it should probably live in the bzr builddeb plugin as one of the help topics. Cause you need it to work UDD style with packages anyway ;-) I did a similar script which just creates a bunch of shared repos and pulls debian ubuntu branches [2] It doesn't attempt to merge it's just there to grab a few merges in one go. Sounds interesting, I'll have a look. To be fair the UDD wiki needs some love from people who used bzr for development. indeed. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On 28 January 2010 06:14, Reinhard Tartler siret...@ubuntu.com wrote: ... Â - download the orig.tar.gz/orig.tar.bz2 files from debian The branches are pristine-tar enabled you can just $ bzr bd them and a tarball will appear in your tarball's directory. Right, but which tarball? It's not always obvious. It's important that we md5sum match Debian [1]. In cases where we don't we end up having to do fake syncs once the differences between Debian and Ubuntu are resolved. Scott K [1] https://bugs.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/510312 -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On 28 January 2010 12:04, Scott Kitterman ubu...@kitterman.com wrote: On 28 January 2010 06:14, Reinhard Tartler siret...@ubuntu.com wrote: ... Â - download the orig.tar.gz/orig.tar.bz2 files from debian The branches are pristine-tar enabled you can just $ bzr bd them and a tarball will appear in your tarball's directory. Right, but which tarball? It's not always obvious. It's important that we md5sum match Debian [1]. In cases where we don't we end up having to do fake syncs once the differences between Debian and Ubuntu are resolved. Well just pick your favorite package branch and inspect it with $bzr visualise or the kde equivalent. The import is quite good. Original tarballs are taken from debian and are imported using pristine-tar into the upstream branch nick. Then the debian packaging is done on the debian branch nick which has upstream as ancestor and then the ubuntu is another branch nick which is diverging from the debian one again. So from the resulting lp:ubuntu/package you can branch off any upstream release, debian or ubuntu package release. And each revision has the corresponding pristine-tarball delta, such that all tarballs can be regenerated with identical checksums as in the debian archive. So the branch import has been engineered really well in this respect and we should not have fake syncs anymore. This even scales to when the branches will get rebased ontop of the upstream releases, cause the pristine-tarball delta will be committed into a new branch nick based off upstream branch adding all the Makefile.in's and etc with the tarball delta. Can't remember either Karmic or Jaunty UDS had a video on this UDD master plan with all the explanations. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On 28 January 2010 12:04, Scott Kitterman ubu...@kitterman.com wrote: On 28 January 2010 06:14, Reinhard Tartler siret...@ubuntu.com wrote: ... Ã - download the orig.tar.gz/orig.tar.bz2 files from debian The branches are pristine-tar enabled you can just $ bzr bd them and a tarball will appear in your tarball's directory. Right, but which tarball? Â It's not always obvious. Â It's important that we md5sum match Debian [1]. Â In cases where we don't we end up having to do fake syncs once the differences between Debian and Ubuntu are resolved. Well just pick your favorite package branch and inspect it with $bzr visualise or the kde equivalent. The import is quite good. Original tarballs are taken from debian and are imported using pristine-tar into the upstream branch nick. Then the debian packaging is done on the debian branch nick which has upstream as ancestor and then the ubuntu is another branch nick which is diverging from the debian one again. So from the resulting lp:ubuntu/package you can branch off any upstream release, debian or ubuntu package release. And each revision has the corresponding pristine-tarball delta, such that all tarballs can be regenerated with identical checksums as in the debian archive. So the branch import has been engineered really well in this respect and we should not have fake syncs anymore. This even scales to when the branches will get rebased ontop of the upstream releases, cause the pristine-tarball delta will be committed into a new branch nick based off upstream branch adding all the Makefile.in's and etc with the tarball delta. Can't remember either Karmic or Jaunty UDS had a video on this UDD master plan with all the explanations. Then maybe the description of what is happening just needs to be improved because as I said in the bug, it sure appears to be looking upstream and getting the tarball from there before it checks Debian. I understand the theory, it isn't clear to me that's what's happening. Scott K -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... Then uses Bryce's merge_changelog script and 'dch -i -m' to handle the repetitive changelog stuff. Ideally, the script would also produce something along the lines of MoM's REPORT, listing the conflicts and giving instructions on how to proceed. I'm looking into working on this bug: https://bugs.edge.launchpad.net/bzr/+bug/160521 Which describes adding a changelog-specific per-file merge for bzr-builddeb. (if you have the plugin, and do 'bzr merge' that contains a merge of a file that looks like 'changelog', then the custom merge algorithm gets invoked for that file.) I'm wondering if you have a link towards where this Bryce's merge_changelog script might exist and how I might get ahold of it as a reference. John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktgHL4ACgkQJdeBCYSNAAM6TgCfXRhg6fJmHMyBFhrqf4+jWipf oeQAoLkNvtEzrtFkMGSW2UpB4XigbMmh =UTKn -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On 2010-01-27 05:00:15 -0600, John Arbash Meinel wrote: I'm looking into working on this bug: https://bugs.edge.launchpad.net/bzr/+bug/160521 Which describes adding a changelog-specific per-file merge for bzr-builddeb. (if you have the plugin, and do 'bzr merge' that contains a merge of a file that looks like 'changelog', then the custom merge algorithm gets invoked for that file.) I'm wondering if you have a link towards where this Bryce's merge_changelog script might exist and how I might get ahold of it as a reference. https://lists.ubuntu.com/archives/ubuntu-distributed-devel/attachments/20100114/6936c7d4/attachment.obj (it was attached to an other mail on this list: https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2010-January/000357.html) As this script does its own version comparison and changelog parsing, you might also want to look at the python-debian package which has a python module for handling changelogs (parsing) and also a python module for Debian version strings. Michael -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Sun, Jan 24, 2010 at 9:22 PM, James Westby jw+deb...@jameswestby.net wrote: On Sun, 17 Jan 2010 23:35:05 -0500, Andrew SB a.star...@gmail.com wrote: Ideally, the script would also produce something along the lines of MoM's REPORT, listing the conflicts and giving instructions on how to proceed. I'm working on something to do this centrally to replace merges.ubuntu.com, but it's not ready for use yet. I'm not sure writing a file when used locally would be all that useful would it? Maybe not... My thought was that it could help ease the transition for folks not yet familiar with using bzr for packaging by providing some instruction locally without having to go searching through the wiki. Of course this can be done in the command's output as well. Any one else have an opinion? -- Andrew SB -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Sun, Jan 24, 2010 at 9:21 PM, James Westby jw+deb...@jameswestby.net wrote: I would love to have something more akin to grab-merge, and again I would be happy to help someone work on this. I would suggest it get added to bzr-builddeb as that will make some things easier. Here's a quick attempt: https://code.edge.launchpad.net/~andrewsomething/bzr-builddeb/bzr-grab-merge Purpose: Grab packaging branchs for merging. Usage: bzr grab-merge PACKAGE Description: This initiates a shared repository and then grabs both lp:ubuntu/package and lp:debian/package. Next, these branches are merged in ./package/working_tree. Mostly I'm hoping that the ugliness of my code (I'm really just a packaging monkey) will scare someone who knows better into stepping up. =) I didn't implement any changelog handling as that seems to be in-progress elsewhere. I suppose the real question here is exactly what features we want this to have. Do we want to generate diffs like the current grab-merge? Do we feel the need to write a REPORT-like file locally? Perhaps bzr help grab-merge should give recipes for the common diffs that we want instead of actually generating them? -- Andrew SB -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Do, Jan 28, 2010 at 00:06:52 (CET), Andrew SB wrote: On Sun, Jan 24, 2010 at 9:21 PM, James Westby jw+deb...@jameswestby.net wrote: I would love to have something more akin to grab-merge, and again I would be happy to help someone work on this. I would suggest it get added to bzr-builddeb as that will make some things easier. Here's a quick attempt: https://code.edge.launchpad.net/~andrewsomething/bzr-builddeb/bzr-grab-merge Purpose: Grab packaging branchs for merging. Usage: bzr grab-merge PACKAGE Description: This initiates a shared repository and then grabs both lp:ubuntu/package and lp:debian/package. Next, these branches are merged in ./package/working_tree. Mostly I'm hoping that the ugliness of my code (I'm really just a packaging monkey) will scare someone who knows better into stepping up. =) I didn't implement any changelog handling as that seems to be in-progress elsewhere. I suppose the real question here is exactly what features we want this to have. Do we want to generate diffs like the current grab-merge? Do we feel the need to write a REPORT-like file locally? I think a 'bzr st -rbranch:../debian' and 'bzr st -rbranch:../ubuntu' would be indeed interesting to have in REPORT. it would be great if grab-merge could additionally - check the freshness of the import branches - download the orig.tar.gz/orig.tar.bz2 files from debian Perhaps bzr help grab-merge should give recipes for the common diffs that we want instead of actually generating them? Yes, that would espc. help people less familiar with bzr. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Mon, 18 Jan 2010 15:33:30 -0500, Barry Warsaw ba...@canonical.com wrote: Unfortunately, the diff that's automatically generated on the merge proposal isn't what Scott wants for the review. As shown above, he really wants the diffs between the branch and current Ubuntu, and branch and current Debian. Perhaps merge proposals for distro packages need a different kind of automatic diff? It could do that, but we would only want it for merge proposals for merges from Debian, and that's tricky to detect, and there is currently no facility to select they type of proposal. In addition, you often want to look at any of a few different types of diffs. To that end I filed a bug against launchpad-code the other day requesting attachments on merge-proposals, which will allow us to attach the extra diffs so the reviewer doesn't have to generate them. We can then provide a wrapper command that proposes the merge and attaches the diffs. If you like this idea then I suggest you go subscribe to the bug report and comment with any further suggestions you have for how the feature should work. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Sun, 17 Jan 2010 23:35:05 -0500, Andrew SB a.star...@gmail.com wrote: Ideally, the script would also produce something along the lines of MoM's REPORT, listing the conflicts and giving instructions on how to proceed. I'm working on something to do this centrally to replace merges.ubuntu.com, but it's not ready for use yet. I'm not sure writing a file when used locally would be all that useful would it? Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Mon, 18 Jan 2010 14:26:48 -0500, Barry Warsaw ba...@canonical.com wrote: I think it would make sense to submit bug reports to help streamline things, but I'm not sure where those bug reports would go. On the bzr-builddeb plugin on Launchpad? Yes, I appreciate everyone's feedback here. I would love to get more feedback in terms of bug reports. Even if you aren't sure that it is a bug as such, if you think something is too complicated then it shows that we probably need to make some changes, and I'm happy to work with you in a bug report to work out what would solve the problem. Plus, bug reports stick around as reminders of what needs to be fixed. bzr-builddeb is a fine place to report them, if you know somewhere more specific then you can do that, but I am happy to reassign if needed. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Wed, 20 Jan 2010 09:36:38 +, Dmitrijs Ledkovs dmitrij.led...@gmail.com wrote: Hmmm = I *think* lp can do this already In the merge proposals options set lp:debian/sid/package as pre-requisite. Then the diff will be the one sponsors require! Wow, that's a cunning idea. I'm not sure it's the right thing to do as it's abusing that field somewhat, and also means it is not free for its intended use should the need arise. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On 18 Jan 2010 12:07:41 +0100, Michael Bienia mich...@bienia.de wrote: On 2010-01-17 22:45:53 -0500, Scott Kitterman wrote: Currently I often insert a step 0 before starting on merging with bzr: - Check if the Debian branch is uptodate. Perhaps I got unlucky when picking a package to merge but several of the packages I wanted to merge had outdated Debian branches so I had to do it by hand (download the Debian .dsc and the Ubuntu delta from PTS and merge it). Yes, this has been a problem due to operational issues. I hope that it will be far less frequent in future. I'm sorry you got hit repeatedly. I usually do a bzr init-repo before and branch both the Ubuntu and Debian branch and use the local Debian branch for merging and diffing. It would be really nice if bzr warned one if the format of local branch and the remote repository differ *before* I start working on something. Please file a bug against bzr. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Mon, 18 Jan 2010 06:56:13 -0600, charlie cj...@cableone.net wrote: On Mon, 2010-01-18 at 12:07 +0100, Michael Bienia wrote: On 2010-01-17 22:45:53 -0500, Scott Kitterman wrote: Currently I often insert a step 0 before starting on merging with bzr: - Check if the Debian branch is uptodate. This has bitten me a few times. When you go to a packages launchpad page under branches, it would be nice if there were links to the ubuntu and debian branches. This way one could quickly determine if the debian branch has been updated. Please file a bug against launchpad-code requesting this. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Sun, 17 Jan 2010 22:45:53 -0500, Scott Kitterman ubu...@kitterman.com wrote: I spent some time over the holidays giving merging via bzr and the UDD tools. I understand that development of the tools to support this is still a work in progress and the much of this feedback probably represents work that you already know needs doing. This mail is based on notes I took recently while doing a merge of regina-normal. As merges go, it was not a complex one. Hi Scott, Thanks for taking the time to try Bazaar and writing up this detailed feedback, it is very valuable. I'm writing this from the perspective of someone who is reasonably familiar with merging using merge-o-matic (~3 years of experience), but relatively knew to bzr. I would have been dead almost immediately if not for the w.u.c documentation [1]. I'm glad there was at least documentation to help you through it. Step 1: Getting the source: Using MoM, I would have grab-merge.sh regina-normal and then had local copies of the common ancestor package, the current Debian package, the current Ubuntu package, and a proposed merge with any conflicting files listed. The UDD equivalent seems to be: $bzr branch lp:ubuntu/regina-normal regina-normal $password for ssh key $cd regina-normal $bzr merge-package lp:debian/squeeze/regina-normal Text conflict in debian/changelog 1 conflicts encountered. The merge resulted in 1 conflicts. Please resolve these and commit the changes with bzr commit. This gives me the proposed merge. The conflict in this case seems to occur with every merge I try. The most recent Debian and Ubuntu debian/changelog entries conflict with each other and the file has to be edited to move the most recent Debian entry above the most recent Ubuntu entry. Additionally, MoM would create a stub changelog entry for the new merged package which was quite convenient. None of this additional work is difficult, but it is tedious and seems ripe for automation. Indeed it is. I'm more than happy to help someone implement these things, they won't be particularly hard, I just have more pressing issues before I get to them. At least the changelog stuff will be resolved before we release Lucid either way. I would love to have something more akin to grab-merge, and again I would be happy to help someone work on this. I would suggest it get added to bzr-builddeb as that will make some things easier. Step 3 checking the package: At this point I want to check the package against the previous Debian and Ubuntu packages to make sure I have it correct. Traditionally, I would locally debdiff the proposed merge with both the previous Debian and Ubuntu packages to make sure I had documented all of the Ubuntu diff and not lost any needed changes in the merge. To do it the new way, I did: $bzr diff --old lp:debian/squeeze/regina-normal | less ssh key (repeat, including redownloading each time the diff is done) I assume bzr diff --old lp:ubuntu/regina-normal would have worked for the diff from the previous Ubuntu package, but it isn't documented and I didn't think to try it at the time. Indeed it would have. Then commit the result: $ bzr ci -m * Update debian/changelog to include undocumented differences from Debian * Remove extraneous whitespace changes Committing to: ~/devel/boost/merge/regina-normal/ modified debian/changelog modified python/testsuite/trigeneral.test Committed revision 20. This method of diffing works fine, except that the previous branch has to be re- downloaded each time the diff is done. In this case I was trying to remove extraneous white space changes that had crept into the packages so it took several tries to get them all. For larger packages or people with a slow internet connection, the need to re-download the diff will have a substantial negative impact. Additionally, I miss a way to diff just the debian directories. For new upstream releases (which this wasn't, so I didn't hit it) I find this a critical way to review the packaging differences between the old and new packages. How did you diff just ./debian/ before if not for filterdiff? Why can't you do that now? Step 4: Building the package: In the old method, I would debuild -S (-sa if needed) -v and have a package ready for uploading. bzr builddeb -S -- -v4.6-1ubuntu1 Now this one looks easy, but has the hidden trap of bzr builddeb providing only -S from dpkg-buildpackage and requiring an extra flag to pass other options to dpkg-buildpackage (--). I think this needs a rethink [2]. Indeed it does. It was never intended to be a lasting solution, but it was a stop-gap from the bzr builddeb -S --builder debuild -S -v4.6-1ubuntu1 that it was before. I knew it was non-obvious, but at least it was there. Again, I will happily help someone who wants to fix this, it should be fairly straightforward. Step 6: Uploading
Re: Feedback on merging via bzr
2010/1/25 James Westby jw+deb...@jameswestby.net: bzr-builddeb is a fine place to report them, if you know somewhere more specific then you can do that, but I am happy to reassign if needed. I guess launchpad.net/udd is not nice place for bugreports? Swamped with what it seems like automatic bug reports -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Mon, 25 Jan 2010 03:35:40 +, Dmitrijs Ledkovs dmitrij.led...@gmail.com wrote: 2010/1/25 James Westby jw+deb...@jameswestby.net: bzr-builddeb is a fine place to report them, if you know somewhere more specific then you can do that, but I am happy to reassign if needed. I guess launchpad.net/udd is not nice place for bugreports? Swamped with what it seems like automatic bug reports It works, and I plan to clear out the automatic reports soon. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
2010/1/19 Michael Hudson michael.hud...@canonical.com: Barry Warsaw wrote: On Jan 17, 2010, at 10:45 PM, Scott Kitterman wrote: At this point I want to check the package against the previous Debian and Ubuntu packages to make sure I have it correct. Traditionally, I would locally debdiff the proposed merge with both the previous Debian and Ubuntu packages to make sure I had documented all of the Ubuntu diff and not lost any needed changes in the merge. To do it the new way, I did: $bzr diff --old lp:debian/squeeze/regina-normal | less ssh key (repeat, including redownloading each time the diff is done) I assume bzr diff --old lp:ubuntu/regina-normal would have worked for the diff from the previous Ubuntu package, but it isn't documented and I didn't think to try it at the time. I just asked Scott to review a change to Lucid's distribute package (python-distribute). I merged debian/sid's version into the ubuntu/lucid version to get us to 0.6.10. Then I committed and pushed a branch to lp:~barry/ubuntu/lucid/distribute/sync-to-sid Unfortunately, the diff that's automatically generated on the merge proposal isn't what Scott wants for the review. As shown above, he really wants the diffs between the branch and current Ubuntu, and branch and current Debian. Perhaps merge proposals for distro packages need a different kind of automatic diff? This can probably be arranged, I guess. File a bug. Patches likely welcome :-) Cheers, mwh Hmmm = I *think* lp can do this already In the merge proposals options set lp:debian/sid/package as pre-requisite. Then the diff will be the one sponsors require! I'm so excited about this. Gonna test this and then comment on the bug. This will then need documentation as part of UDD-docs. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
Barry Warsaw wrote: On Jan 17, 2010, at 10:45 PM, Scott Kitterman wrote: At this point I want to check the package against the previous Debian and Ubuntu packages to make sure I have it correct. Traditionally, I would locally debdiff the proposed merge with both the previous Debian and Ubuntu packages to make sure I had documented all of the Ubuntu diff and not lost any needed changes in the merge. To do it the new way, I did: $bzr diff --old lp:debian/squeeze/regina-normal | less ssh key (repeat, including redownloading each time the diff is done) I assume bzr diff --old lp:ubuntu/regina-normal would have worked for the diff from the previous Ubuntu package, but it isn't documented and I didn't think to try it at the time. I just asked Scott to review a change to Lucid's distribute package (python-distribute). I merged debian/sid's version into the ubuntu/lucid version to get us to 0.6.10. Then I committed and pushed a branch to lp:~barry/ubuntu/lucid/distribute/sync-to-sid Unfortunately, the diff that's automatically generated on the merge proposal isn't what Scott wants for the review. As shown above, he really wants the diffs between the branch and current Ubuntu, and branch and current Debian. Perhaps merge proposals for distro packages need a different kind of automatic diff? This can probably be arranged, I guess. File a bug. Patches likely welcome :-) Cheers, mwh -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Jan 20, 2010, at 11:10 AM, Michael Hudson wrote: This can probably be arranged, I guess. File a bug. Patches likely welcome :-) For now: https://bugs.edge.launchpad.net/launchpad-code/+bug/509901 -Barry signature.asc Description: PGP signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On 2010-01-18 16:18:44 +1100, Andrew Bennetts wrote: That's right. If you're interested, bug 491711 https://bugs.launchpad.net/bzr/+bug/491711 is tracking progress on this, and there's a branch at adds the hook point going through code review at the moment. Perhaps there should be a bzr-builddeb bug (or bug task on 491711?) too? I've filed a bug against bzr-builddeb about this before I knew about the ongoing work on hooks: https://bugs.launchpad.net/bugs/501754 (Better support for merging debian/changelog) Michael -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On 2010-01-17 22:45:53 -0500, Scott Kitterman wrote: Currently I often insert a step 0 before starting on merging with bzr: - Check if the Debian branch is uptodate. Perhaps I got unlucky when picking a package to merge but several of the packages I wanted to merge had outdated Debian branches so I had to do it by hand (download the Debian .dsc and the Ubuntu delta from PTS and merge it). Step 1: Getting the source: Using MoM, I would have grab-merge.sh regina-normal and then had local copies of the common ancestor package, the current Debian package, the current Ubuntu package, and a proposed merge with any conflicting files listed. The UDD equivalent seems to be: $bzr branch lp:ubuntu/regina-normal regina-normal $password for ssh key $cd regina-normal $bzr merge-package lp:debian/squeeze/regina-normal I usually do a bzr init-repo before and branch both the Ubuntu and Debian branch and use the local Debian branch for merging and diffing. It would be really nice if bzr warned one if the format of local branch and the remote repository differ *before* I start working on something. I merged fuse the usual way (and used bzr init-repo for storing the branches) and when I was about to push the branch towards my LP account for sponsoring, I got told that bzr can't push it because the LP branch uses a different format. I branched the Ubuntu branch once again (this time without bzr init-repo so it keeps its format) and kind of redid the merge (I copied the changed files from the other branch into this one). This time the pushing worked. But it cost me unnecessary time. Michael -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Mon, 2010-01-18 at 12:07 +0100, Michael Bienia wrote: On 2010-01-17 22:45:53 -0500, Scott Kitterman wrote: Currently I often insert a step 0 before starting on merging with bzr: - Check if the Debian branch is uptodate. This has bitten me a few times. When you go to a packages launchpad page under branches, it would be nice if there were links to the ubuntu and debian branches. This way one could quickly determine if the debian branch has been updated. Best regards Charlie -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
2010/1/18 Scott Kitterman ubu...@kitterman.com: I spent some time over the holidays giving merging via bzr and the UDD tools. I understand that development of the tools to support this is still a work in progress and the much of this feedback probably represents work that you already know needs doing. This mail is based on notes I took recently while doing a merge of regina-normal. As merges go, it was not a complex one. I'm writing this from the perspective of someone who is reasonably familiar with merging using merge-o-matic (~3 years of experience), but relatively knew to bzr. I would have been dead almost immediately if not for the w.u.c documentation [1]. Step 1: Getting the source: Using MoM, I would have grab-merge.sh regina-normal and then had local copies of the common ancestor package, the current Debian package, the current Ubuntu package, and a proposed merge with any conflicting files listed. The UDD equivalent seems to be: $bzr branch lp:ubuntu/regina-normal regina-normal $password for ssh key $cd regina-normal $bzr merge-package lp:debian/squeeze/regina-normal I do $bzr init-repo package $cd package $bzr branch lp:ubuntu/package lucid $bzr branch lp:debian/package squeeze Text conflict in debian/changelog 1 conflicts encountered. The merge resulted in 1 conflicts. Please resolve these and commit the changes with bzr commit. Hopefully per-file hook will solve this Step 2 working on the package: Step 3 checking the package: At this point I want to check the package against the previous Debian and Ubuntu packages to make sure I have it correct. Traditionally, I would locally debdiff the proposed merge with both the previous Debian and Ubuntu packages to make sure I had documented all of the Ubuntu diff and not lost any needed changes in the merge. To do it the new way, I did: $bzr diff --old lp:debian/squeeze/regina-normal | less ssh key (repeat, including redownloading each time the diff is done) At this point in the package/lucid branch you have all package revisions and tags so you can do this : $bzr diff -r tag:0.1-3ubuntu5 #debdiff against old ubuntu $bzr diff -r tag:0.1-6 #debdiff against debian Or any package release for that matter. see $bzr tags Also you might want to add --prefix=old-version/:new-version/ such that bzr diff looks like debdiff. I assume bzr diff --old lp:ubuntu/regina-normal would have worked for the diff from the previous Ubuntu package, but it isn't documented and I didn't think to try it at the time. Again use your local revisions. After you grab debian ubuntu branch disconnect your network =) It will make you think UDD way. Then commit the result: $ bzr ci -m * Update debian/changelog to include undocumented differences from Debian * Remove extraneous whitespace changes Committing to: ~/devel/boost/merge/regina-normal/ modified debian/changelog modified python/testsuite/trigeneral.test Committed revision 20. Better use debcommit it takes new entries from debian/changlog and appends --fixes lp:XX such that when you push this branch it will get linked to bugs in lp. This method of diffing works fine, except that the previous branch has to be re- downloaded each time the diff is done. In this case I was trying to remove extraneous white space changes that had crept into the packages so it took several tries to get them all. For larger packages or people with a slow internet connection, the need to re-download the diff will have a substantial negative impact. Additionally, I miss a way to diff just the debian directories. For new upstream releases (which this wasn't, so I didn't hit it) I find this a critical way to review the packaging differences between the old and new packages. No see above Step 4: Building the package: In the old method, I would debuild -S (-sa if needed) -v and have a package ready for uploading. bzr builddeb -S -- -v4.6-1ubuntu1 ? huh I just use $bzr bd#regular build $bzr bd --quick #customised to build with pbuilder (should be named slow) $bzr bd --source #create source package Now this one looks easy, but has the hidden trap of bzr builddeb providing only -S from dpkg-buildpackage and requiring an extra flag to pass other options to dpkg-buildpackage (--). I think this needs a rethink [2]. See builddeb manual for builddeb.conf Step 5: Testing the package: This is orthogonal to UDD, so I won't cover it. Step 6: Uploading the package: I don't have upload rights so I can't comment. $ dput ubuntu regina-normal_4.6-1.1ubuntu1_source.changes At this point, I'd be done under the old method (and I could have stopped here now and let the branch be created from the uploaded package, but I decided to persevere). $ bzr mark-uploaded $ bzr push lp:ubuntu/regina-normal ssh key ... Now we are done and have both an updated package in the archive and an updated branch on
Re: Feedback on merging via bzr
On Mon, Jan 18, 2010 at 12:21 PM, Scott Kitterman ubu...@kitterman.com wrote: I usually use the ancestor revision shortcut for selecting the revision to diff: Ubuntu patch compared to the common base version: ~/src/pkg-name/lucid/ $ bzr diff -rancestor:../squeeze/ Debian patch compared to the common base version: ~/src/pkg-name/squeeze/ $ bzr diff -rancestor:../lucid/ These two commands should generate the equivalent of the .patch files from MoM. That doesn't solve the issue with the data being local versus remote, but it definitely looks very helpful. As mentioned earlier in the thread, it makes sense to always work from local branches with a local repository: 1. Create a local repository: ~/src/$ bzr init-repo src-pkg-name 2. Checkout latest Ubuntu version: ~/src/pkg-name/$ bzr co lp:ubuntu/pkg-name/ lucid 3. Checkout latest Debian version: ~/src/pkg-name/$ bzr co lp:debian/pkg-name/ squeeze 4. Create a local branch to work on the merge: ~/src/pkg-name/$ bzr branch lucid l-merge Would you add that to the wiki page on merging? Done (it's a wiki page - anyone can edit it ;) ). -- Mathias Gug Ubuntu Developer http://www.ubuntu.com -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Jan 17, 2010, at 10:45 PM, Scott Kitterman wrote: I spent some time over the holidays giving merging via bzr and the UDD tools. I understand that development of the tools to support this is still a work in progress and the much of this feedback probably represents work that you already know needs doing. This mail is based on notes I took recently while doing a merge of regina-normal. As merges go, it was not a complex one. This is good stuff Scott. It mirrors some of my recent experience using UDD to do various kinds of development. Of course, my packaging experience is weeks old, not years old :), so I don't have much comparison of the traditional way to draw on. The UDD equivalent seems to be: $bzr branch lp:ubuntu/regina-normal regina-normal $password for ssh key ssh-agent helps here so that you only have to enter this once. $cd regina-normal $bzr merge-package lp:debian/squeeze/regina-normal Text conflict in debian/changelog 1 conflicts encountered. The merge resulted in 1 conflicts. Please resolve these and commit the changes with bzr commit. This gives me the proposed merge. The conflict in this case seems to occur with every merge I try. The most recent Debian and Ubuntu debian/changelog entries conflict with each other and the file has to be edited to move the most recent Debian entry above the most recent Ubuntu entry. Yep, I noticed exactly the same thing. To get ready to start to work on the actual merge, I need to also do: $ vim debian/changelog (re-arrange as described) $ bzr resolve All conflicts resolved. Emacs to the rescue here (for the crazy people who use it :). Emacs auto-resolves files when you save them. It's a nice convenience that hasn't bitten me yet :). Step 3 checking the package: At this point I want to check the package against the previous Debian and Ubuntu packages to make sure I have it correct. Traditionally, I would locally debdiff the proposed merge with both the previous Debian and Ubuntu packages to make sure I had documented all of the Ubuntu diff and not lost any needed changes in the merge. To do it the new way, I did: $bzr diff --old lp:debian/squeeze/regina-normal | less ssh key (repeat, including redownloading each time the diff is done) It would probably be better branch these locally if you're going to do a lot of diffing. I know a huge amount of work has gotten to getting things as far as they are. This feedback is not meant to miminize this accomplishment. I do not, however, feel like this facility is really ready for general use yet. I think it would make sense to submit bug reports to help streamline things, but I'm not sure where those bug reports would go. On the bzr-builddeb plugin on Launchpad? -Barry signature.asc Description: PGP signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Jan 17, 2010, at 10:45 PM, Scott Kitterman wrote: I spent some time over the holidays giving merging via bzr and the UDD tools. I understand that development of the tools to support this is still a work in progress and the much of this feedback probably represents work that you already know needs doing. This mail is based on notes I took recently while doing a merge of regina-normal. As merges go, it was not a complex one. Oh, also, there are some interesting steps you took that I did not notice were documented on the wiki page. Maybe you can take a pass through them and update them with some of the things you learned (e.g. bzr mark-uploaded, diffing the Ubuntu and Debian sources). https://wiki.ubuntu.com/DistributedDevelopment/Documentation -Barry signature.asc Description: PGP signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Mon, Jan 18, 2010 at 12:21 PM, Scott Kitterman ubu...@kitterman.com wrote: I usually use the ancestor revision shortcut for selecting the revision to diff: Ubuntu patch compared to the common base version: ~/src/pkg-name/lucid/ $ bzr diff -rancestor:../squeeze/ Debian patch compared to the common base version: ~/src/pkg-name/squeeze/ $ bzr diff -rancestor:../lucid/ These two commands should generate the equivalent of the .patch files from MoM. That doesn't solve the issue with the data being local versus remote, but it definitely looks very helpful. As mentioned earlier in the thread, it makes sense to always work from local branches with a local repository: 1. Create a local repository: ~/src/$ bzr init-repo src-pkg-name 2. Checkout latest Ubuntu version: ~/src/pkg-name/$ bzr co lp:ubuntu/pkg-name/ lucid 3. Checkout latest Debian version: ~/src/pkg-name/$ bzr co lp:debian/pkg-name/ squeeze 4. Create a local branch to work on the merge: ~/src/pkg-name/$ bzr branch lucid l-merge Would you add that to the wiki page on merging? Done (it's a wiki page - anyone can edit it ;) ). Certainly, but I think wiki edits should generally be done by people who understand what they are talking about. In this area, I don't particularly qualify yet. Thanks, Scott K -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On Mo, Jan 18, 2010 at 04:45:53 (CET), Scott Kitterman wrote: This method of diffing works fine, except that the previous branch has to be re- downloaded each time the diff is done. In this case I was trying to remove extraneous white space changes that had crept into the packages so it took several tries to get them all. For larger packages or people with a slow internet connection, the need to re-download the diff will have a substantial negative impact. As already mentioned, fetching both branches (the ubuntu and debian import) into a local repository mitigates this problem. The 'grab-merge'-like wrapper that you proposed could and probably should do exactly that. Additionally, I miss a way to diff just the debian directories. For new upstream releases (which this wasn't, so I didn't hit it) I find this a critical way to review the packaging differences between the old and new packages. This is possible and in fact for me a killer argument for using DVCS tools for managing packages in the first place: bzr diff --old lp:debian/package debian/control for diffing only debian control, or bzr diff --old lp:debian/package debian for diffing the debian subdirectory only. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
forgot mailing list sorry silly gmail So then you get to read the reply twice. ;-) -- Forwarded message -- From: Dmitrijs Ledkovs dmitrij.led...@gmail.com Date: 2010/1/18 Subject: Re: Feedback on merging via bzr To: Scott Kitterman ubu...@kitterman.com 2010/1/18 Scott Kitterman ubu...@kitterman.com: Ubuntu patch compared to the common base version: ~/src/pkg-name/lucid/ $ bzr diff -rancestor:../squeeze/ Debian patch compared to the common base version: ~/src/pkg-name/squeeze/ $ bzr diff -rancestor:../lucid/ These two commands should generate the equivalent of the .patch files from MoM. That doesn't solve the issue with the data being local versus remote, but it definitely looks very helpful. Â Would you add that to the wiki page on merging? Scott K What do you mean? These commands _do not_ require access to remote branches at all! It's all local no trips to launchpad. I'd missed that he was working from local checkouts when I read the message. Scott K -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
On 2010-01-18 03:45, Scott Kitterman wrote: Text conflict in debian/changelog 1 conflicts encountered. The merge resulted in 1 conflicts. Please resolve these and commit the changes with bzr commit. This gives me the proposed merge. The conflict in this case seems to occur with every merge I try. The most recent Debian and Ubuntu debian/changelog entries conflict with each other and the file has to be edited to move the most recent Debian entry above the most recent Ubuntu entry. Additionally, MoM would create a stub changelog entry for the new merged package which was quite convenient. None of this additional work is difficult, but it is tedious and seems ripe for automation. At least for the changelog issue, Bazaar is moving forward with per-file conflict resolution hooks that will allow type-specific merge behavior for things like changelogs. -- David Strauss | da...@fourkitchens.com Four Kitchens | http://fourkitchens.com | +1 512 454 6659 [office] | +1 512 870 8453 [direct] signature.asc Description: OpenPGP digital signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
Thanks for writing this Scott. It touches on a couple things I've been meaning to write about myself. On Sun, Jan 17, 2010 at 10:45 PM, Scott Kitterman ubu...@kitterman.com wrote: 1. The most important change would be to have some kind of a wrapper for getting the source. It would be nice to have a script that would download branches for the common ancestor, current Ubuntu, and current Debian branches, and do the proposed merge. Without local access to the different versions of the package, it is very difficult to know if you've got a correct merge. I think this is an important point. Especially with MoM not updating correctly, we really need something to help ease people into these new methods. I think a grab-merge like script would go a long way to helping both simplify the repetitive work as well as introduce people to UDD methods. I've personally been using a hackish shell script that I'd be embarrassed to distributed. It basically does: bzr init-repo $PACKAGE cd $PACKAGE bzr branch lp:ubuntu/$PACKAGE $PACKAGE-ubuntu bzr branch lp:debian/$PACKAGE $PACKAGE-debian bzr branch $PACKAGE-ubuntu working-tree cd working-tree bzr merge-package ../$PACKAGE-debian Then uses Bryce's merge_changelog script and 'dch -i -m' to handle the repetitive changelog stuff. Ideally, the script would also produce something along the lines of MoM's REPORT, listing the conflicts and giving instructions on how to proceed. In the old method, I would debuild -S (-sa if needed) -v and have a package ready for uploading. bzr builddeb -S -- -v4.6-1ubuntu1 Now this one looks easy, but has the hidden trap of bzr builddeb providing only -S from dpkg-buildpackage and requiring an extra flag to pass other options to dpkg-buildpackage (--). I think this needs a rethink [2]. I didn't know that was even possible. I've been using bzr bd --builder=debuild -S -v4.6-1ubuntu1 I very much agree with: 3. As mentioned, the bzr builddeb interface and documentation needs work. Ideally it would act similarly to debuild and pass all the dpkg-buildpackage options to it without special flags. Yet another interface that is almost the same is problematic. - Andrew Starr-Bochicchio -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
2010/1/18 Scott Kitterman ubu...@kitterman.com: I feel like I've gone through a process that is far more complex than the old one for no real benefit. I have some recommendations for improving and simplifying this process. I think simplification is an essential element because the learning curve for new contributors is very steep already and raising the barrier to entry is not something that will benefit Ubuntu. Thanks for the feedback, and yes, a major point of this is to make contribution easier not harder. So we need to smooth off some fairly rough edges. 1. The most important change would be to have some kind of a wrapper for getting the source. It would be nice to have a script that would download branches for the common ancestor, current Ubuntu, and current Debian branches, and do the proposed merge. Without local access to the different versions of the package, it is very difficult to know if you've got a correct merge. Additionally, if there were checkouts for the previous Debian and Ubuntu packages locally, then it should be easy enough to diff the debian directories to check for packaging changes when a new upstream version is involved. That sounds good, and not too hard to do. 2. As you no doubt know, the changelog merging could be better and would reduce repetitive, boring work potential contributors have to do. Andrew has a framework for this up for review, so we should be able to integrate the existing code for debian/changelog merging. We will probably also cut out the explicit and I think unnecessary 'bzr resolve' step. -- Martin http://launchpad.net/~mbp/ -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Feedback on merging via bzr
David Strauss wrote: On 2010-01-18 03:45, Scott Kitterman wrote: Text conflict in debian/changelog 1 conflicts encountered. The merge resulted in 1 conflicts. Please resolve these and commit the changes with bzr commit. This gives me the proposed merge. The conflict in this case seems to occur with every merge I try. The most recent Debian and Ubuntu debian/changelog [...] At least for the changelog issue, Bazaar is moving forward with per-file conflict resolution hooks that will allow type-specific merge behavior for things like changelogs. That's right. If you're interested, bug 491711 https://bugs.launchpad.net/bzr/+bug/491711 is tracking progress on this, and there's a branch at adds the hook point going through code review at the moment. Perhaps there should be a bzr-builddeb bug (or bug task on 491711?) too? Using that hook point I've successfully written a custom merge for bzr's NEWS file, so it should be suitable for debian/changelog files too. I'm about to go on paternity leave, but many bzr devs will sprinting together next week. I've suggested they take a look at creating a custom merge for debian/changelog files; considering there's some code already written for doing 2-way merges of that file (see https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2010-January/000357.html) it shouldn't be too hard. -Andrew. -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
