Re: RFC: updated workflow [WAS: Re: git+patch workflow]
- From: Slava Zanko <slavazanko gmail com>
- To: Patrick Winnertz <winnie debian org>, mc devel <mc-devel gnome org>
- Subject: Re: RFC: updated workflow [WAS: Re: git+patch workflow]
- Date: Sun, 04 Jan 2009 23:13:04 +0200
-----BEGIN PGP SIGNED MESSAGE-----
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
tested
there by different people. (Everybody who has tested it should report
to the
ticket)
- 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'
stage?
> 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)
+1
WBR, Slavaz.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAklhJlkACgkQb3oGR6aVLppC3gCdGdMTREyrGenDs38MD8VEmjN5
5WoAnA6B4mpIoY31mOpmXBxQ4lusM5Zn
=Skqn
-----END PGP SIGNATURE-----
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]