Re: Import layout of Quilt v3 packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... >> You can maintain the property as well by adding a hook that applies the >> patches at checkout time. (Even that hook is not strictly necessary, as >> debuild will automatically apply patches at build time as necessary.) >> >> To me this question if patches should be applied to the branch or not >> seems to be a presentation issue, which should better be handled at >> presentation level. > > Personally, I agree that not applying branches in the branch is the best > way to work properly with the current tools available. > Honestly, I don't care a whole lot about "the current tools available". What we want to shoot for is how would you actually like to work. If the best we can get to is "it is only 1 more step to work the way you used to work" then we've failed, because all we've done is make the process *more* complicated. I'm happy to provide some support for gradual transition, and compatibility. But this shouldn't be designed around "let's make it work like it used to, only with extra steps added because we want to use bzr". Versioning the history without the patches applied is pretty silly, IMO. It means you get practically 0 benefit from using bzr. (unless maybe other people find bzr qannotate debian/patches/00-add-foo to be particularly enlightening. :) John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1StI4ACgkQJdeBCYSNAAPIzQCeN1BWv+pQ1o3MsanLRt8T4k0D 5D0An3nJywcriDsnNFoItyPZQABqNQuj =HBhG -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: Import layout of Quilt v3 packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/9/2011 6:08 AM, Barry Warsaw wrote: > On Feb 09, 2011, at 07:57 AM, Reinhard Tartler wrote: > >>> meaning all patches are already applied in the source branch. >> -1 >> >> You can maintain the property as well by adding a hook that applies the >> patches at checkout time. (Even that hook is not strictly necessary, as >> debuild will automatically apply patches at build time as necessary.) > > Actually, if the branch were converted to loom format, then "all patches > already applied" would simply mean that a checkout would leave you at the top > thread. > > -Barry > I think having tools like 'annotate' and 'log' show you the changes to actual content, rather than showing you the changes to a patch file seems to make a lot more sense. If you have a hook that makes the working tree deb-compatible, it can just as easily tell something like 'debuild' that the patches are already applied. John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1SsksACgkQJdeBCYSNAAMrdgCgvCGzhKoTu3yJe25mSEp0RUkD x9IAoLRdxdNMy4xjUKdun6K5i7hGqQBW =0coN -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: Import layout of Quilt v3 packages
On Feb 09, 2011, at 07:57 AM, Reinhard Tartler wrote: >> meaning all patches are already applied in the source branch. >-1 > >You can maintain the property as well by adding a hook that applies the >patches at checkout time. (Even that hook is not strictly necessary, as >debuild will automatically apply patches at build time as necessary.) Actually, if the branch were converted to loom format, then "all patches already applied" would simply mean that a checkout would leave you at the top thread. -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: Import layout of Quilt v3 packages
On 09/02/11 06:57, Reinhard Tartler wrote: > > On Di, Feb 08, 2011 at 00:26:16 (CET), Barry Warsaw wrote: >>> 1) As I understand it, most people are in favor of *not* versioning the >>> .pc directory. So that when you do "bzr branch lp:ubuntu/foo" you'll >>> get a tree with: >> >> I agree with James that 1) the .pc directory should not be versioned, and 2) >> we want to keep the property of branch-and-hack, > > +1 > >> meaning all patches are already applied in the source branch. > -1 > > You can maintain the property as well by adding a hook that applies the > patches at checkout time. (Even that hook is not strictly necessary, as > debuild will automatically apply patches at build time as necessary.) > > To me this question if patches should be applied to the branch or not > seems to be a presentation issue, which should better be handled at > presentation level. Personally, I agree that not applying branches in the branch is the best way to work properly with the current tools available. But, there has been one good reason for applied patches in the branch given: it allows examination of the history of the actual code used to build the package, via the native tools of the Bazaar. Though, given how much it complicates simple changes to the branch, I don't think it pays off overall. Max. 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: Import layout of Quilt v3 packages
On Di, Feb 08, 2011 at 00:26:16 (CET), Barry Warsaw wrote: >>1) As I understand it, most people are in favor of *not* versioning the >> .pc directory. So that when you do "bzr branch lp:ubuntu/foo" you'll >> get a tree with: > > I agree with James that 1) the .pc directory should not be versioned, and 2) > we want to keep the property of branch-and-hack, +1 > meaning all patches are already applied in the source branch. -1 You can maintain the property as well by adding a hook that applies the patches at checkout time. (Even that hook is not strictly necessary, as debuild will automatically apply patches at build time as necessary.) To me this question if patches should be applied to the branch or not seems to be a presentation issue, which should better be handled at presentation level. -- 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: Import layout of Quilt v3 packages
On 08/02/11 17:36, Micah Gersten wrote: > On 02/08/2011 08:23 AM, Max Bowsher wrote: >> On 08/02/11 13:52, James Westby wrote: >>> On Tue, 08 Feb 2011 08:00:25 +, Max Bowsher wrote: Therefore, what about checking in the patched code, without any quilt metadata (.pc dir) but with a flag file that triggers bzr-builddeb to write out the appropriate metadata whenever a working tree is built for such a branch? (Writing out the metadata would consist of copying the series file to .pc/applied-patches, and reverse-applying each patch in reverse order, stashing the resultant modified file in .pc// for each patch) >>> This would work for checkout. What are the implications for merge etc? >> On consideration, the implications for merge are not pleasant. >> >> You'd need to quilt pop -a, merge the upstream (despite now having local >> modifications from popping), resolve conflicts, don't commit, quilt >> push, resolving conflicts in pushing the patches, and finally commit. Yuck. >> >> So, now I've realized the above, I'd go so far as to suggest that there >> is no reasonable branch format in between "patches as quilt series, >> *not* applied" and "full loomification". >> >> I think we should go ahead and change the package importer _now_ to >> revert to importing 3.0 (quilt) source packages with patches *not* >> applied. When it does so, it should probably write a >> "debian/source/local-options" file containing "unapply-patches". This >> will give us import branches that are actually usable for UDD-style >> development *now*, which I think we currently do not have for 3.0 >> (quilt) packages. >> >> Once the problems surrounding ubiquitous looms have been solved, we can >> think about switching the import format again, but at least we will then >> have usable UDD between now and when we reach that point. >> >> Max. >> > > I don't see quilt pop -a working without a .pc directory. Isn't the .pc > directory part of the source upload in source format 3? The .pc directory is not part of an upload. It is created by dpkg-source at extraction time. Currently it is then committed verbatim by the package importer. I am suggesting that it not be committed, but be synthesized at checkout time. Either way, it exists in the working copy when you are about to do a merge, which is when my quilt pop -a above is suggested. Max. 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: Import layout of Quilt v3 packages
On 02/08/2011 08:23 AM, Max Bowsher wrote: > On 08/02/11 13:52, James Westby wrote: >> On Tue, 08 Feb 2011 08:00:25 +, Max Bowsher wrote: >>> Therefore, what about checking in the patched code, without any quilt >>> metadata (.pc dir) but with a flag file that triggers bzr-builddeb to >>> write out the appropriate metadata whenever a working tree is built for >>> such a branch? >>> >>> (Writing out the metadata would consist of copying the series file to >>> .pc/applied-patches, and reverse-applying each patch in reverse order, >>> stashing the resultant modified file in .pc// for >>> each patch) >> This would work for checkout. What are the implications for merge etc? > On consideration, the implications for merge are not pleasant. > > You'd need to quilt pop -a, merge the upstream (despite now having local > modifications from popping), resolve conflicts, don't commit, quilt > push, resolving conflicts in pushing the patches, and finally commit. Yuck. > > So, now I've realized the above, I'd go so far as to suggest that there > is no reasonable branch format in between "patches as quilt series, > *not* applied" and "full loomification". > > I think we should go ahead and change the package importer _now_ to > revert to importing 3.0 (quilt) source packages with patches *not* > applied. When it does so, it should probably write a > "debian/source/local-options" file containing "unapply-patches". This > will give us import branches that are actually usable for UDD-style > development *now*, which I think we currently do not have for 3.0 > (quilt) packages. > > Once the problems surrounding ubiquitous looms have been solved, we can > think about switching the import format again, but at least we will then > have usable UDD between now and when we reach that point. > > Max. > I don't see quilt pop -a working without a .pc directory. Isn't the .pc directory part of the source upload in source format 3? Micah -- 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: Import layout of Quilt v3 packages
On Feb 08, 2011, at 02:23 PM, Max Bowsher wrote: >I think we should go ahead and change the package importer _now_ to >revert to importing 3.0 (quilt) source packages with patches *not* >applied. When it does so, it should probably write a >"debian/source/local-options" file containing "unapply-patches". This >will give us import branches that are actually usable for UDD-style >development *now*, which I think we currently do not have for 3.0 >(quilt) packages. > >Once the problems surrounding ubiquitous looms have been solved, we can >think about switching the import format again, but at least we will then >have usable UDD between now and when we reach that point. It's not entirely unusable now. It's also not entirely awesome either. https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem Discovered with much experimentation. -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: Import layout of Quilt v3 packages
On 08/02/11 13:52, James Westby wrote: > On Tue, 08 Feb 2011 08:00:25 +, Max Bowsher wrote: >> Therefore, what about checking in the patched code, without any quilt >> metadata (.pc dir) but with a flag file that triggers bzr-builddeb to >> write out the appropriate metadata whenever a working tree is built for >> such a branch? >> >> (Writing out the metadata would consist of copying the series file to >> .pc/applied-patches, and reverse-applying each patch in reverse order, >> stashing the resultant modified file in .pc// for >> each patch) > > This would work for checkout. What are the implications for merge etc? On consideration, the implications for merge are not pleasant. You'd need to quilt pop -a, merge the upstream (despite now having local modifications from popping), resolve conflicts, don't commit, quilt push, resolving conflicts in pushing the patches, and finally commit. Yuck. So, now I've realized the above, I'd go so far as to suggest that there is no reasonable branch format in between "patches as quilt series, *not* applied" and "full loomification". I think we should go ahead and change the package importer _now_ to revert to importing 3.0 (quilt) source packages with patches *not* applied. When it does so, it should probably write a "debian/source/local-options" file containing "unapply-patches". This will give us import branches that are actually usable for UDD-style development *now*, which I think we currently do not have for 3.0 (quilt) packages. Once the problems surrounding ubiquitous looms have been solved, we can think about switching the import format again, but at least we will then have usable UDD between now and when we reach that point. Max. 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: Import layout of Quilt v3 packages
On Tue, 08 Feb 2011 08:00:25 +, Max Bowsher wrote: > Therefore, what about checking in the patched code, without any quilt > metadata (.pc dir) but with a flag file that triggers bzr-builddeb to > write out the appropriate metadata whenever a working tree is built for > such a branch? > > (Writing out the metadata would consist of copying the series file to > .pc/applied-patches, and reverse-applying each patch in reverse order, > stashing the resultant modified file in .pc// for > each patch) This would work for checkout. What are the implications for merge etc? 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: Import layout of Quilt v3 packages
On Feb 08, 2011, at 06:00 PM, Martin Pool wrote: >At the moment it seems to me we need to either: import to looms and >mandate using looms; or check in things with everything expanded and >provide glue that will keep the quilt data up to date with the wt. >(Perhaps they should be considered derived data and updated from a >hook.) One other use case to keep in mind: it's sometimes necessary to remove quilt patch files. One of the things you do when you merge in a new upstream is to review the current set of patches to see what's been applied upstream. You'll delete those patches, and of course may need to resolve conflicts in subsequent patches that touch the same code. I think that would correspond to a combine-thread in the loom that throws away the changes in one thread. -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: Import layout of Quilt v3 packages
On 8 February 2011 19:00, Max Bowsher wrote: > On 08/02/11 07:00, Martin Pool wrote: >> At the moment it seems to me we need to either: import to looms and >> mandate using looms; or check in things with everything expanded and >> provide glue that will keep the quilt data up to date with the wt. >> (Perhaps they should be considered derived data and updated from a >> hook.) > > I don't think we want to be checking in .pc at all. > > Personally I quite like the simplicity of just checking in the package > with the patches NOT applied, but I gather people like being able to > navigate the actual history of the patched package. > > Therefore, what about checking in the patched code, without any quilt > metadata (.pc dir) but with a flag file that triggers bzr-builddeb to > write out the appropriate metadata whenever a working tree is built for > such a branch? > > (Writing out the metadata would consist of copying the series file to > .pc/applied-patches, and reverse-applying each patch in reverse order, > stashing the resultant modified file in .pc// for > each patch) Right, that's what I meant by my (somewhat unclear) second option. -- 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: Import layout of Quilt v3 packages
On 08/02/11 07:00, Martin Pool wrote: > On 5 February 2011 03:45, James Westby wrote: >> On Fri, 04 Feb 2011 10:22:45 -0600, John Arbash Meinel >> wrote: >>> Now that I've described the state as I understand it, here are some >>> questions. >>> >>> 1) As I understand it, most people are in favor of *not* versioning the >>>.pc directory. So that when you do "bzr branch lp:ubuntu/foo" you'll >>>get a tree with: >>> a) debian/patches/* still intact >>> b) Those patches applied to the working tree >>> c) no .pc directory >> >> Well, I'm in favour of *not* versioning the .pc directory, however I >> don't immediately follow to your a, b and c. >> >> I am convinced that "check out and immediately start hacking" is a >> property that we want. > > Very well put. > > At the moment it seems to me we need to either: import to looms and > mandate using looms; or check in things with everything expanded and > provide glue that will keep the quilt data up to date with the wt. > (Perhaps they should be considered derived data and updated from a > hook.) I don't think we want to be checking in .pc at all. Personally I quite like the simplicity of just checking in the package with the patches NOT applied, but I gather people like being able to navigate the actual history of the patched package. Therefore, what about checking in the patched code, without any quilt metadata (.pc dir) but with a flag file that triggers bzr-builddeb to write out the appropriate metadata whenever a working tree is built for such a branch? (Writing out the metadata would consist of copying the series file to .pc/applied-patches, and reverse-applying each patch in reverse order, stashing the resultant modified file in .pc// for each patch) Max. 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: Import layout of Quilt v3 packages
On 5 February 2011 03:45, James Westby wrote: > On Fri, 04 Feb 2011 10:22:45 -0600, John Arbash Meinel > wrote: >> Now that I've described the state as I understand it, here are some >> questions. >> >> 1) As I understand it, most people are in favor of *not* versioning the >> .pc directory. So that when you do "bzr branch lp:ubuntu/foo" you'll >> get a tree with: >> a) debian/patches/* still intact >> b) Those patches applied to the working tree >> c) no .pc directory > > Well, I'm in favour of *not* versioning the .pc directory, however I > don't immediately follow to your a, b and c. > > I am convinced that "check out and immediately start hacking" is a > property that we want. Very well put. At the moment it seems to me we need to either: import to looms and mandate using looms; or check in things with everything expanded and provide glue that will keep the quilt data up to date with the wt. (Perhaps they should be considered derived data and updated from a hook.) -- Martin -- 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: Import layout of Quilt v3 packages
On Feb 04, 2011, at 10:22 AM, John Arbash Meinel wrote: >d) How often is it that patches are directly layered on top of > each other (textually)? So patch 1 makes it 'hello\nworld\n' and > patch 2 changes it to "hello world\n". Or some other "patch 1 must \ > be applied before patch 2 makes *any* sense" I think it's fairly common that patches are layered. Certainly the ui for quilt implies a strong stacked relationship between the patches. > Because if they all are textually different, then it is strictly > redundant. But otherwise it is possible for one to introduce state > that another mutates, which wouldn't be reflected in the working > state. > >e) looms, still a bit of a question how this interacts with everything > else. I'd say, "not so well" ;) https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem >1) As I understand it, most people are in favor of *not* versioning the > .pc directory. So that when you do "bzr branch lp:ubuntu/foo" you'll > get a tree with: I agree with James that 1) the .pc directory should not be versioned, and 2) we want to keep the property of branch-and-hack, meaning all patches are already applied in the source branch. >All this may change again if we switch the importer to use looms, since >then you can do stuff like merge the patches one-by-one up the stack >until you get to the top, without having to deal with conflicts in .diff >format. It'll be really nice if I can work on a quilt3 package with just moving up and down the threads. -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: Import layout of Quilt v3 packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... > There is a similar problem with the current state of affairs, where > merging two branches attempts to merge everything in .pc and doesn't > leave you in a very good state. I would imagine that merging a .pc directory could easily corrupt the state. Certainly I wouldn't expect 3-way merge of a .bzr pack repository to leave you with anything that would actually work. > >> All this may change again if we switch the importer to use looms, since >> then you can do stuff like merge the patches one-by-one up the stack >> until you get to the top, without having to deal with conflicts in .diff >> format. > > Exactly. > > I think that there may be a middle ground, if we can separate > storage from presentation to the user. I don't know how that would work > without some pretty major changes though. Maybe pursuing looms is the > correct way to go. > > Thanks, > > James > See my next thread, where I discuss loom merge, and how to handle the 3-tip problem. (You have diverged patches, *and* you're merging up from upstream.) John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1MMSkACgkQJdeBCYSNAAN7/QCffBhyjOcql4Z0oVmDrbFoo+cB RMUAnjoYcXuxAxH7iQ3Qh19sfVujQK4b =2WdK -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: Import layout of Quilt v3 packages
On Fri, 04 Feb 2011 10:22:45 -0600, John Arbash Meinel wrote: > Now that I've described the state as I understand it, here are some > questions. > > 1) As I understand it, most people are in favor of *not* versioning the >.pc directory. So that when you do "bzr branch lp:ubuntu/foo" you'll >get a tree with: > a) debian/patches/* still intact > b) Those patches applied to the working tree > c) no .pc directory Well, I'm in favour of *not* versioning the .pc directory, however I don't immediately follow to your a, b and c. I am convinced that "check out and immediately start hacking" is a property that we want. > 2) Doesn't that mean that you have to rebuild the .pc directory right >after you get the checkout? Wouldn't it be easier to get it from the >beginning? Or is it just introducing an extra place to get conflicts >when trying to merge. Yes, you would have to rebuild the .pc directory right after the checkout. Yes it would be easier to get it right from the beginning. >That said, if you did end up merging 2 branches that didn't have .pc >directories, how would you get the .pc directory rebuilt? (Since >presumably the patch series need to be combined in some way, and >modifications to the source tree also need to be replicated into the >patches themselves.) There is a similar problem with the current state of affairs, where merging two branches attempts to merge everything in .pc and doesn't leave you in a very good state. > All this may change again if we switch the importer to use looms, since > then you can do stuff like merge the patches one-by-one up the stack > until you get to the top, without having to deal with conflicts in .diff > format. Exactly. I think that there may be a middle ground, if we can separate storage from presentation to the user. I don't know how that would work without some pretty major changes though. Maybe pursuing looms is the correct way to go. 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
