RFC: updated workflow [WAS: Re: git+patch workflow]

Patrick Winnertz winnie at debian.org
Mon Jan 5 06:24:26 UTC 2009


> delete *the* stable branch, but not the concept of stable branches per
> se. doing so would mean that once you merged a feature patch to master,
> you cannot do a bugfix release any more until you make a feature release
> (*). to keep the option of bugfix releases open (and distributors really
> want that), one should always make a release branch from master (say,
> 4.6) and branch for bugfix patches from that branch. then one can make
> a bugfix release (say, 4.6.3) from the 4.6 branch at any time. the
> release branch is merged into master (but not the other way round) after
> each fix. of course that requires upfront planning whether a particular
> patch needs to go into a possible bugfix release, but given the patch
> branch process, you have a good start for that (the proposal in your
> next mail seems reasonable).
This was the way I planned it actually before writting my email. After 
rethinking the stuff I thought it would also be possible to only work with 
master without having stable branches. 
The disadvantage is that a pure bugfix release won't be possible (since master 
is also used for development.)

Okay as I think think this makes sense:

[copy & paste from a older mail]:
 - if a ticket contains a patch the acceptor of this ticket create a branch 
(*) 
with this patch applied 
 - people can test it there and comment in this ticket
 - if they have an enhancment they can fix it in git (and push it to the server 
of course ;-)) and add a updated patch (for tracking the issue) to the 
bugreport. If the patch in it's latest version is acked the branch get merged 
back into the parent branch. Then we have only one ack step and not two 
anymore.

(*): based on, wether it should be a bugfix for a stable tree, mc-4.6 or if it 
should be a new feature, on master. If created on a stable release branch this 
fix is also merged back after it is applied on the release branch into the 
master branch.

Now, how to handle the ticket states with this workflow:
After a ticket is created it is new.. When someone accepts it it is set to
accepted. When someone has a patch which is worth to be added to a git branch, 
this should be done. Then the ticket can be set to testing as this is 
currently the case (We test if the patch is okay). If two people acked the 
patch (they really should test it and not only look on the sourcecode), the 
branch with the fix inside will be merged by the acceptor of the ticket this 
branch belongs too, into the appropiate branch (e.g. mc-4.6 or master). Then 
the ticket will be set to closed.

The same if we develop after 4.6.2 own new stuff: 
 A ticket is opened with the idea inside... Someone develops a new feature 
based on master in a  branch. After he thinks that this task is done he adds a 
patch to the report and set the report to testing. Then someone can look at 
his work  and comment in the ticket. After the patch is fine this branch get 
merged into master (and the ticket is closed).

>
> (*) actually, one can retroactively create a release branch from a
> past master revision on demand. anyway, that results in a mess, as the
> need for cherry picking is practically guaranteed in that case. on top
> of that, the release process as such becomes a mess ("if a release
> branch exists, tag there, otherwise tag on master. think of this, don't
> forget that, and, oh, if you are religious: pray").
This is a mess and was never intended :) 

Greetings
Winnie

-- 
 . '' ` .   Patrick Winnertz <winnie at debian.org>
:  :'   :   proud Debian developer, author, administrator, and user
`. `'`     http://people.debian.org/~winnie - http://www.der-winnie.de
  `-  Debian - when you have better things to do than fixing systems
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.midnight-commander.org/pipermail/mc-devel/attachments/20090105/154e2f3a/attachment.asc>


More information about the mc-devel mailing list