Re: [Pkg-javascript-devel] git-buildpackage workflow
Quoting Jérémy Lal (2012-12-16 00:13:31) On 15/12/2012 21:27, Jonas Smedegaard wrote: Quoting Jérémy Lal (2012-12-15 20:32:35) i want to switch to a simpler and more efficient way of using gbp branches for the packages i am maintaining : * always import on upstream branch * work on latest versions is made on master branch * create branches of master when needed, but use them only for bug fixing (typically: master-wheezy) No more master-experimental, upstream-experimental couples How then to handle cases where latest upstream version is not latest *stable* upstream version? I mean - a very common use for the experimental suite is to try out newer upstream releases known to not yet be mature enough for unstable. The problem i have is having to merge master-experimental onto master. It doesn't work well, it ends up not being a merge at all, rather a rewrite upon (an auxiliary branch is needed to simulate git merge --theirs by using a reverse git merge --ours). I have no trouble understanding what problem you try to solve. What I do have trouble with is understanding how that does not create other problems. Essentially work targeted experimental is a fork, hoped to later become adopted as the future mainline work. What you want to do now is to treat it as mainline from the start, essentially treating later progress on that old-mainline as being a fork. That is bad, because that means we do not track linear progress of work applied to unstable. Experimental is a throw-away area in the sense that we do not promise linear progression there, as we do in unstable, testing, stable and oldstable. I recognize it is unavoidable to have couples of branches like here (master-1.4, upstream-1.4). Instead of treating experimental as a fork of mainline work as we do today, you want to treat unstable as a fork and experimental as our mainline. However, the latest version eventually is the stable one, and when it does it is already on the main branch. No: There is no guarantee that what we do in experimental will end up in unstable. We might learn from our experiments that we are better off throwing it away and only cherry-pick good parts of what we did there. The model i propose is just about branching off when dealing with stable version : (master, upstream) - (master-1.4, upstream-1.4) in order to always keep latest version on (master, upstream). This avoids the first problem, while having a very similar structure of repository. I dare say it does not avoid problems, only shifts where the problems are. I like that our current structures work well for unstable, testing, stable and oldstable - i.e. that it is only tricky to handle experimental which we make no promises for anyway. I suspect the better approach than force-merging with --strategy ours would be to rebase experimental on top of master. If you insist on trating experimental as mainline, could you perhaps check if anyone else in Debian does similar and has documented their practice and experiences with it? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] git-buildpackage workflow
On 16/12/2012 12:40, Jonas Smedegaard wrote: I like that our current structures work well for unstable, testing, stable and oldstable - i.e. that it is only tricky to handle experimental which we make no promises for anyway. I suspect the better approach than force-merging with --strategy ours would be to rebase experimental on top of master. If you insist on trating experimental as mainline, could you perhaps check if anyone else in Debian does similar and has documented their practice and experiences with it? Damn me, i did not understand that rebase was what i was missing. Thank you for your answers, i won't insist. Jérémy. signature.asc Description: OpenPGP digital signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] git-buildpackage workflow
Hi, i want to switch to a simpler and more efficient way of using gbp branches for the packages i am maintaining : * always import on upstream branch * work on latest versions is made on master branch * create branches of master when needed, but use them only for bug fixing (typically: master-wheezy) No more master-experimental, upstream-experimental couples i carelessly setup couple of years ago, and that don't follow how git branches are supposed to be used. For this to work gbp must have this option : pristine-tar = True Also to avoid having to update debian/gbp.conf for each branch of master, i'd like to use this option : ignore-branch = True gbp will (by default) find correct tags on upstream branch, and whatever the developer is doing, he's supposed to be on the right debian branch, so just ignore it. If you are concerned by those packages (mainly redmine, nodejs, libv8, npm, because others didn't have experimental branches), please add your comments. Jérémy. ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] git-buildpackage workflow
On 15/12/2012 21:27, Jonas Smedegaard wrote: Quoting Jérémy Lal (2012-12-15 20:32:35) i want to switch to a simpler and more efficient way of using gbp branches for the packages i am maintaining : * always import on upstream branch * work on latest versions is made on master branch * create branches of master when needed, but use them only for bug fixing (typically: master-wheezy) No more master-experimental, upstream-experimental couples How then to handle cases where latest upstream version is not latest *stable* upstream version? I mean - a very common use for the experimental suite is to try out newer upstream releases known to not yet be mature enough for unstable. The problem i have is having to merge master-experimental onto master. It doesn't work well, it ends up not being a merge at all, rather a rewrite upon (an auxiliary branch is needed to simulate git merge --theirs by using a reverse git merge --ours). Let me simulate some work on package xxx : * import 1.4.1 to upstream and merge to master * work on master * release 1.4.1-1 to unstable * import 2.0 to upstream and merge to master * work on master * release 2.0-1 to experimental * import 1.4.2 to upstream oops ! I agree that keeping only one upstream branch cannot work. Last step should be : * branch upstream-1.4 upstream/1.4.1 * branch master-1.4 debian/1.4.1-1 * import 1.4.2 to upstream-1.4 and merge to master-1.4 * work on master-1.4 * release 1.4.2-1 to unstable I recognize it is unavoidable to have couples of branches like here (master-1.4, upstream-1.4). However, the latest version eventually is the stable one, and when it does it is already on the main branch. The model i propose is just about branching off when dealing with stable version : (master, upstream) - (master-1.4, upstream-1.4) in order to always keep latest version on (master, upstream). This avoids the first problem, while having a very similar structure of repository. Jérémy. ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
