Hash: SHA1

Patrick Winnertz wrote:

Some my additions for discuss...

> Please comment:
 - There should be a separate branch for each patch. The branch with the
patch should be created by developer (who accept patch or by ticketstarter);
> - every patch has to be acked twice
  --> if patch is broken a *-rev2.patch (rev3, revN) has to be created
(from branch) and be discussed
  --> Subsequent patches must be created relative from point of fork branch
 - a acked patch has to be merged in a branch of master and needs to be
 there by different people. (Everybody who has tested it should report
to the
 - after some testing  the branch with patch will deleted (and the
 ticket is closed)
 - if testing fail, create new branch with patch... hm, need to discuss
this situation.

> This is pretty much the old stuff above (now we create a branch for every 
> ticket (proposed branchname 1234_something_describing).
'one branch mean one patch(set)' it's good idea, imho. In my local
git-repro this already so is.

BTW, may be a situation in which no one askes for the patch (no time or
busy, lazy, don't want to take responsibility for the consequences of a
patch, etc). What do in this case?

And what do if no testing reports? Is ticket leave in 'always testing'

> When we want to do a release:
> Simply do a tag on mc-4.6.2~rc1 
>  --> Test it and if it is okay tag also mc-4.6.2
>  --> Otherwise mc-4.6.2~rc2
>  --> Test it and if it is okay tag here mc-4.6.2
>  --> ...
> In the meantime new patches can be discussed and tested as written above.. 
> After the release we rebase the branches and merge them into master.
Good. Like a kernel-develop schema. Like for me.

> ps:  If this is okay I'll delete the stable branch and update/write a bit 
> about this workflow to our wiki)

WBR, Slavaz.
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

Mc-devel mailing list

Reply via email to