[Pkg-javascript-devel] git-buildpackage workflow

[Jonas Smedegaard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20121216/caa91057/attachment-0001.pgp>