Hi, In my mind it was kind of making more sense to start by keeping 4.6 into a separate branch, enforce pull-requests and deploy the CI. smaller step but faster result, and from there, once we get stable with the CI and git flow; move into master, do fastest releases cycle. If we consider we can do all that starting in 4.6, I'm all for it!
Marcus: are you preparing a proposal on this? wiki page? I can help Seb: doesn't the vote would confirm the consensus? Raja: do we have any documentation somewhere on how to use, contribute to the smoke test? that could be our start for the CI tests? Cheers On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <run...@gmail.com> wrote: > > > On Apr 29, 2015, at 9:49 PM, Marcus <shadow...@gmail.com> wrote: > > > > After reviewing the history as mentioned by Daan, unless we propose > > and vote on a newer workflow model I think the best we can do is to > > simply be more strict about commits to master. They all need to be > > merges that have been tested against master before merge. This will in > > theory make master more stable, but doesn't really change the workflow > > we've already agreed upon and have been working under (although > > bugfixes sometimes were not coming in from branches, and cherry-picked > > bugfixes from branches will need to go into a branch first, tested > > against master, and merged to master). We can essentially set a date > > and do that any time, with some advance notice that direct commits > > will be reverted. > > Yes +1. > > -Set a date > -Tag master for reference > -Find a volunteer or two to RM master > -automatic revert on master if not from RM > -all commits to master come from PR, need clear review and green tests > -harden master (basic QA process), release 4.6 as a tag on master > -all features and fixes need to be made on branches or forks and onus is > on devs to rebase to master > -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3, 4.4, > etc) > -from there forward only maintain a linear release through master > > Feel free to add, tweak > > PS: No need to vote if we have consensus. Taking a clue from ASF members, > votes should be avoided at all cost, they mean that we do not have clear > consensus. > > > > > > On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <run...@gmail.com> > wrote: > >> > >>> On Apr 18, 2015, at 8:36 AM, Marcus <shadow...@gmail.com> wrote: > >>> > >>> Have they diverged that much? Due to cherry-picking, I guess. > >>> Otherwise you should be able to do it cleanly. > >>> > >>> There's a good opportunity to do this next release. Instead of > >>> creating a release branch, we freeze master and start creating dev > >>> branches. > >> > >> +1 > >> > >> This just amounts to treating master now like a release branch. Getting > back to PL suggestion, that means > >> that any commit to master would be through a PR or MERGE request on the > ML. Anything else will be reverted by the RM. > >> > >> Marcus, do you feel like writing down a little process for this and > some dates that we can target. > >> It would be nice to do this for 4.6. > >> > >>> > >>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland < > daan.hoogl...@gmail.com> wrote: > >>>> We heavily invested in code now on master. Not looking forward to > >>>> backporting that. > >>>> > >>>> mobile dev with bilingual spelling checker used (read at your own > risk) > >>>> Op 17 apr. 2015 21:02 schreef "Marcus" <shadow...@gmail.com>: > >>>> > >>>>> Well, would we just swap the last release branch with master? Master > >>>>> is the dev branch, and the last release is really what we have as a > >>>>> stable branch. > >>>>> > >>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland < > daan.hoogl...@gmail.com> > >>>>> wrote: > >>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen < > run...@gmail.com> > >>>>> wrote: > >>>>>>> > >>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com > > > >>>>> wrote: > >>>>>>>> > >>>>>>>> Today during the CloudStackdays we did a round table about > Release > >>>>>>>> management targeting the next 4.6 releases. > >>>>>>>> > >>>>>>>> > >>>>>>>> Quick bullet point discussions: > >>>>>>>> > >>>>>>>> ideas to change release planning > >>>>>>>> > >>>>>>>> - Plugin contribution is complicated because often a new plugin > >>>>> involve > >>>>>>>> change on the core: > >>>>>>>> - ex: storage plugin involve changes on Hypervisor code > >>>>>>>> - There is an idea of going on a 2 weeks release model which could > >>>>>>>> introduce issue the database schema. > >>>>>>>> - Database schema version should be different then the application > >>>>>>>> version. > >>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger > >>>>> simulator > >>>>>>>> job on PullRequest. > >>>>>>>> - Some people (I'm part of them) are concerned on our current way > of > >>>>>>>> supporting and back porting fixes to multiple release (4.3.x, > 4.4.x, > >>>>>>>> 4.5.x). But the current level of confidence against latest release > >>>>> is low, > >>>>>>>> so that need to be improved. > >>>>>>>> > >>>>>>>> > >>>>>>>> So, the main messages is that w'd like to improve the release > >>>>> velocity, and > >>>>>>>> release branch stability. so we would like to propose few change > in > >>>>> the > >>>>>>>> way we would add code to the 4.6 branch as follow: > >>>>>>>> > >>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge > >>>>> request, > >>>>>>>> which would trigger a simulator job, ideally only if that pass > the PR > >>>>> would > >>>>>>>> be accepted and automatically merged. At this time, I think we > pretty > >>>>> much > >>>>>>>> have everything in place to do that. At a first step we would use > >>>>>>>> simulator+marvin jobs then improve tests coverage from there. > >>>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> We do need to realize what this means and be all fine with it. > >>>>>>> > >>>>>>> It means that if someone who is not RM directly commits to the > release > >>>>> branch, the commit will be reverted. > >>>>>>> And that from the beginning of the branching… > >>>>>> I agree and we can even go as far as reverting fixes that are > >>>>>> cherry-picked in favour of merged forward. > >>>>>> > >>>>>>> > >>>>>>> IMHO, I think this would be a good step but I don’t think it goes > far > >>>>> enough. > >>>>>> Agreed here as well but let's take the step while discussing further > >>>>>> steps and not implement to much process as well > >>>>>> > >>>>>>> > >>>>>>> This still uses a paradigm where a release is made from a release > >>>>> branch that was started from an unstable development branch. > >>>>>>> Hence you still need *extensive* QA. > >>>>>> The problem here is that there is no stable point to fork from at > the > >>>>>> moment. We will get there and we shouldn't stop taking steps in that > >>>>>> direction. > >>>>>> > >>>>>>> > >>>>>>> If we truly want to release faster, we need to release from the > same > >>>>> QA’d branch time after time….a release needs to be based on a > previous > >>>>> release > >>>>>>> > >>>>>>> Basically, we need a rolling release cycle. That will have the > added > >>>>> benefit to not leave releases behind and have to focus on > backporting. > >>>>>>> > >>>>>>>> > >>>>>>>> Please comments :-) > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Daan > >>>>> > >> > >
