Workflow Idea for 4.10

[Alexander Neundorf]

On Friday 16 March 2012, Kevin Ottens wrote:
> Hello,
> 
> On Wednesday 14 March 2012 14:38:19 Aaron J. Seigo wrote:
> > [...]
> > this is what really piques my interest: merge based workflow.
> > 
> > an integration branch would be fantastic. that branch should rebase
> > periodically off of master and only be used to merge feature branches.
> > this branch would largely take the place of current master: where
> > development "happens". feature branches should be merged into
> > integration on a regular basis and developers and testers should track
> > this integration branch in their day-to-day usage
> > 
> > integration should always be open to feature branch merging. master
> > should only be open for feature merge when not in freeze, however.
> > 
> > when in freeze, either a stabilization branch could be made off of master
> > for this purpose (probably a very good idea for larger fixes) which is
> > then merged down in master at known good points .. or .. master is
> > opened for bug fixes directly in those periods. the latter is probably
> > not as "good" from a stability POV, but may be more reasonable and less
> > of a workload for people doing the actual work.
> > 
> > so what i'm interested in hearing is what sort of branch management
> > scheme would work for people. i'm happy to maintain either an
> > integration or the master branch (but not both).
> > [...]
> > 
> > note that the methods being (slowly) adopted for frameworks devel are
> > also moving in the direction noted above.
> 
> I'd just like to add my 0.02€ here.
> 
> I've been thinking about the git workflow to be used in KDE Frameworks in
> the future. Based on observations and discussions with current and future
> frameworks maintainer, I think that it would be a mistake to force a
> single workflow for all the frameworks. I'm not 100% sure what the final
> solution will be but it's likely to end up being a short list of blessed
> workflows: 1) Full game, one branch per feature with review time in an
> integration/testing branch before hitting master;
>  2) Intermediate, one branch per feature with merge in master after
> reviewers/maintainer validation;
>  3) Easy, features directly developped in master[1].

Sounds good.
But OTOH, having one workflow for KDE frameworks (i.e. not even all of KDE SC) 
would be also a really good thing to have. It will make contributing easier.
Would 2) be an option for KDE frameworks ?


Alex