On 27/07/17 18:14, Stefan Schmidt wrote: > Hello. > > On 07/27/2017 10:18 AM, Simon Lees wrote: >> >> >> On 27/07/17 17:33, Stefan Schmidt wrote: >>> Hello. >>> >>> On 07/22/2017 11:22 PM, Andrew Williams wrote: >>>> Hi eflers :) >>>> >>>> So after thinking about issue management and planning milestones I >>>> thought >>>> more about our source control. We currently have various different >>>> models >>>> used but the bottom line is that it all hits master all the time which >>>> can >>>> lead to less stability than ideal and also makes stabilisation windows >>>> critical to enforce. >>>> >>>> As a suggestion I think we should consider agreeing on a singlet >>>> branching >>>> model and I'd recommend GitFlow (described quite well here >>>> https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow). >>>> >>>> >>>> As well as being well organised there is a solid gitflow plugin that >>>> helps >>>> to manage branches and workflows. >>> >>> I read the tutorial now. It is the first time I ever encountered this >>> workflow. Do you know any bigger FOSS projects that use this? The ones >>> I'm familiar with do not (not even EDI, which is unstable on master from >>> time to time. ;)) >>> >> Qt uses this workflow or atleast was last time I was paying attention to >> there development. I'm also in the group thinking this development model >> is better then our current one (but not enough to passionately argue >> for it) > > Hmm, my understanding was that Qt had a master branch which was only > getting commits coming through a CI system after review and testing > passed. Having all actual development work in feature branches without > any shared develop branch. But I got that impression many years back > from a presentation Thiago did. > > You surely do know more about the Qt devel workflow than I do. I will > try to have a look what they do over the next days. to understand better > how it fits with a active FOSS project. Thanks for the tip. > > regards > Stefan Schmidt >
As of 2 - 3 years back it was something along the lines of bugfix-x.x(one per version) / stable / development. Anything that was a bugfix ie suitable to go into a point release (1.19.2) would go directly to the bugfix branch while development for the next stable release (1.20) was in the "stable" branch, periodically the "bugfix" branch gets merged back into the "stable" branch so bugfixes go there as well. "Development" contains any new features not going into 1.20, periodically "stable" gets merged back into "development" so that the diff doesn't grow too big. When 1.20 is released the "bugfix-1.20" branch is created from "stable" (similar to what we have now except all bugfixes go into that branch first). The "development" branch is then merged into "stable". Before 1.21 is "frozen" new features that people think will land in 1.21 can be submitted direct to stable if the freeze has started or the feature wont be ready they can go into the "development" branch, obviously as we get closer to release more will go in "development" rather then "stable" They obviously have more contributors though. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
