> 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 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
Attachment:
signature.asc
Description: This is a digitally signed message part.