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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel