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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel