Workflow Idea for 4.10

[Kevin Ottens]

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].

The choice for a given framework to use one or the other workflow will likely 
be left up to the maintainer discretion. I guess the criteria to pick a 
workflow will be:
 * Overall size of the framework;
 * Overall number of contributors;
 * Spread of the contributors in the framework repository (aka how independent 
from each other contributions are, linked to the internal complexity of the 
framework);
 * Automated tests coverage;
 * Overall modularity of the framework (e.g. lots of small plugins or not);
 * Probably more that I missed so far.

I think that's also relevant to the current discussion at hand for the 
workspaces. It's reaching a critical mass in size, and you might want to have 
a similar balanced position instead of a one size fit all being unilateraly 
applied on every one.

Of course kde-workspace is in a different situation since AFAIK there's not 
plan to have finer grained repositories. In which case "one size fit all" 
might sound more realistic to reduce confusion... Just please try to be 
careful with the "oh look shiny cool tool" effect (been there...[3]), which 
generally don't solve social problems or might even create new ones ("be 
careful what you ask, you might get it").

Definitely more food for thought than anything in the context of the 
workspaces. Thought it could help finding the right course. ;-)

Regards.

[1] And before any "we should always branch" zealot cringe (not blaming you, 
been there as well), please take a few minutes and read[2]:
http://martinfowler.com/bliki/FeatureToggle.html
If you want to be really complete you can also stop by:
http://martinfowler.com/bliki/FeatureBranch.html
(but maybe not necessary)

[2] BTW, Martin Fowler has really great pieces in his "bliki" it's definitely 
worth spending time reading in there.

[3] And of course regularly fall in the trap again. :-)
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120316/c37c9ee1/attachment-0001.sig>