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
* 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
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
-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
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
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
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
