> On May 11, 2015, at 2:00 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > > +1 how about my proposal to have 6 RM and demand that at least 2 agree on > each PR?
+0.5 we can say that we need two pairs of eyes to ok the PR for merge. no need to formally have 6 RMs ? so 1 RM (you or me) + another pair of eyes would work ? > > Op ma 11 mei 2015 om 09:52 schreef sebgoa <run...@gmail.com>: > >> >> On May 6, 2015, at 10:59 AM, Daan Hoogland <daan.hoogl...@gmail.com> >> wrote: >> >>> I can have a look at the merge of 4.5.1 and am willing to be one of the >>> RMs, not to be the RM! >>> >> >> I can RM as well. >> >> How about we lock down master on wednesday ? >> From that point forward we only take PR into master -either you or me- all >> other direct commits to master will be reverted !!!! >> >> >> -sebastien >> >> >> >>> Op wo 6 mei 2015 om 09:47 schreef sebgoa <run...@gmail.com>: >>> >>>> So no -1 on this. >>>> >>>> Do we have volunteers to RM 4.6 on the master branch ? >>>> >>>> I propose to set a date asap, tag master and tell everyone that starting >>>> from that tag all commits to master except from RM will be reverted. >>>> >>>> will need to make sure that all of 4.5.1 is in master >>>> >>>> -sebastien >>>> >>>> >>>> On May 1, 2015, at 1:19 PM, Daan Hoogland <daan.hoogl...@gmail.com> >> wrote: >>>> >>>>> Let's not do more quality improvement proces but just improve quality. >> If >>>>> anybody want to add to the pages on the wiki, you're welkom but nobody >>>> did >>>>> for long time. +1 for the present state of Sebastien's views on things. >>>> We >>>>> can refine at any time. >>>>> >>>>> Op vr 1 mei 2015 om 09:55 schreef sebgoa <run...@gmail.com>: >>>>> >>>>>> >>>>>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pdion...@apache.org> >>>> wrote: >>>>>> >>>>>>> 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 >>>>>> >>>>>> I hear you. >>>>>> >>>>>> But we have waited for way too long for better CI. I see great efforts >>>> in >>>>>> that direction. >>>>>> But I personally do not want to wait any longer to make a move. >>>>>> >>>>>> We do open source, we should have fun, take risks, move fast, fail >> fast, >>>>>> recover etc…. >>>>>> >>>>>> so let's JFDI >>>>>> >>>>>>> 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! >>>>>> >>>>>> >>>>>> Is there really a difference between creating a 4.6 and doing what you >>>>>> say, and tagging master (start) and doing it on master leading to 4.6 >>>>>> release ? >>>>>> >>>>>> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If >> we >>>>>> can improve a bit on the QA then we win. >>>>>> Plus I think a different commit model will help a lot in quality. >>>>>> >>>>>>> >>>>>>> Marcus: are you preparing a proposal on this? wiki page? I can help >>>>>>> >>>>>> >>>>>> We can do this proposal on email..and once we have consensus write it >> up >>>>>> for archive in the wiki. >>>>>> If we move to the wiki now, this effort is going to die. >>>>>> >>>>>>> Seb: doesn't the vote would confirm the consensus? >>>>>>> >>>>>> >>>>>> if we have consensus no need for vote. >>>>>> >>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >>
