Re: [Jack-Devel] JACK2 branching

Le 9 avr. 2011 à 21:41, Nedko Arnaudov a écrit :

> After a discussion with Stephane and Devin, I've created a wiki page [1]
> that aims to describe the jack2 branching, in SVN and GIT. The page is
> still in draft state but I'd like to announce its existence and raise
> some related questions.
> 
> ATM only the svn trunk - git master branch relation is strictly
> maintained. This is mainly because I'm not entirely sure what we should
> do with the other jack2 svn branches. I think that the libjacknet and
> pipelining SVN branches are active ones because Stephane rebases them
> From time to time.

Yes. 

- "libjacknet" is a branch with some cleanup and CELT support for NetJack2, as well as a exposed API (the net.h file in public headers) to access NetJack protocol without having to run a Jack server. I did that for some experiments with iPhone for instance.  But since there is still this NetJack1/NetJack2, I don't know what do to with this development on the long term...

- "pipelining" is the stuff allowing to better use mutiprocessor machines with pure sequential part in the jack graph?


> Maybe there are other.

No AFIACS.


> Do you think it it a good idea
> to switch to git only workflow for them?

It would certainly help. How difficult would it be. I we decide to do that, I guess I should rebase form SVN trunk before right?


> Do we really have to maintain
> svn (non-trunk) branches when we can maintain them as other git only
> branches?

Probably not.

> 
> What are the git only workflows involved? IIRC, so far we had three
> cases of git branch use.
> 
> * my ladi-related branches. They are not really used for collaboration
>   but for maintenance of jack2 codebase modifications. I.e. they are
>   long living branches.
> * The netjack1 and jack-session branches (Torben)

Not sure of their "liveness" state... Torben ?

> * The new MIDI branches (Devin/Stephane)

Already merged on SVN trunk for the most part, but sill used By Devin for improvements.

> 
> Is there are need to define the practices used for collaboration between
> developers in git branch? This is a pure git workflow and as such there
> are less restrictions than when git-svn is involved. I think that we
> should favour rebases when for commits that are not yet pushed and
> merges for already pushed commits. Still, I've not actively participated
> in pure GIT branch collaboration and thus it makes more sense to
> document what the current practices are, especially the good ones. If we
> manage to define some good GIT workflow, maybe we will face less GIT
> mess in future. And yes, with GIT we can (and did) generate lot of mess
> because it is powerful and with few inherent restrictions.
> 
> Should we delete already merged branches?


I guess yes for unused one like: 

devin-resolving
devin-merge-20110405
newer-midi-with-winmme-driver (merge in newer-midi that continue its own life)
newer-midi-with-coremidi-driver  (merge in newer-midi that continue its own life)
server-ctl-proposal (already merged)
new-midi ==> replaced by newer-midi

mob ??
js-rebase ??
jack-session ?? (Torben ??)

What is the git command to delete a remote branch?

> Should we have a history log
> of branching/merging?

Would help yes.

> 
> If you have comments about the current content of the wiki page, I'm
> open for them. If you like to act bold, feel free to correct and improve
> that page, but please describe the reality, not the desired future,
> especially if you know that it is controversial.
> 
> [1] http://trac.jackaudio.org/wiki/jack2_branching
> 

Did some additions. 

Stéphane

1302427039.8687_0.ltw:2,a <AB55B1C2-BB8A-46D3-BAE1-400EA08FB341 at grame dot fr>