Re: RFC: updated workflow [WAS: Re: git+patch workflow]
Am Montag 05 Januar 2009 15:13:48 schrieb Enrico Weigelt: * Oswald Buddenhagen o...@kde.org schrieb: Hi, 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 Actually, I dislike that idea. Instead we should declare, that 'master' branch is *always* what becomes the next release. We just have to take care that it's always in a state that it could be released ASAP - so: *no* development there. New features only get committed if they're really ready to get into next release (which in theory could come any second). Well.. I like the idea of mc-4.6 stable branch quite much as we can then do point releases there which is only bugfixing and do active development in master on e.g. utf8 support or.. or or... This has this advantage: - we release mc-4.6.2 from mc-4.6 branch Tested utf8 very much and include it in master - there is now a smaller issue but we doesn't want to release e.g .4.7 (with utf8) yet -- make a pointrelease with that fix applied and work further on master With your scenario we have troubles here, because we can't make a smaller point release fixing only some bugs without introducing new big features which should be reserved for a new bigger release. Fixes done in mc-4.6 branches can then be merged back into master so that master contains always every patch. I hope that this sound logically for you and I we can work this way :) Greetings Winnie -- . '' ` . Patrick Winnertz win...@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 signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: updated workflow [WAS: Re: git+patch workflow]
* Oswald Buddenhagen o...@kde.org schrieb: Hi, 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 Actually, I dislike that idea. Instead we should declare, that 'master' branch is *always* what becomes the next release. We just have to take care that it's always in a state that it could be released ASAP - so: *no* development there. New features only get committed if they're really ready to get into next release (which in theory could come any second). Of course we should do stable tree releases quite frequently, *NOT* collecting too much which might introduce new bugs. We've already waited too long w/ 4.6.2. (and distributors really want that), Well, if distros want a bugfixed branch of older releases and don't want to take care all by themselves, they could simply join the OSS-QM project, which is meant as an bug-fixing overlay over existing *releases* (it's about QM exclusively, *NO* development). But according the lack of interest in all these years, the presure obviously can't be that hight ;-o cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
RFC: updated workflow [WAS: Re: git+patch workflow]
Hey because of Oswald Buddenhagen's post I rethinked the workflow and discussed a better workflow with slavaz. Please comment: - every patch has to be acked twice -- if patch is broken a rev2 has to be created and be discussed - a acked patch has to be applied 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 in the branch we merge into the master branch (and the ticket is closed) This is pretty much the old stuff above (now we create a branch for every ticket (proposed branchname 1234_something_describing). 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. Please comment. Greetings Winnie ps: If this is okay I'll delete the stable branch and update/write a bit about this workflow to our wiki) -- . '' ` . Patrick Winnertz win...@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 signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: updated workflow [WAS: Re: git+patch workflow]
-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- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: updated workflow [WAS: Re: git+patch workflow]
Hey, - 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. See below my suggestion. This is pretty much the old stuff above (now we create a branch for every ticket (proposed branchname 1234_something_describing). 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? Well.. if this will be the case in the future we have to rethink the idea.. but until at least 3 people are more or less active this shouldn't happen. And what do if no testing reports? Is ticket leave in 'always testing' stage? Okay to fasten the process a bit up: - 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 master branch. Then we have only one ack step and not two anymore. 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 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). Hope this helps to make it someone easier. Greetings Winnie -- . '' ` . Patrick Winnertz win...@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 signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: updated workflow [WAS: Re: git+patch workflow]
On Sun, Jan 04, 2009 at 09:28:29PM +0100, Patrick Winnertz wrote: ps: If this is okay I'll delete the stable branch and update/write a bit about this workflow to our wiki) 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). (*) 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). ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: updated workflow [WAS: Re: git+patch workflow]
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 win...@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 signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
