I'm fine with that: rm must have a reviewer on merges? Seem heavy for trivial changes but alright
On Mon, 11 May 2015 14:16 Sebastien Goasguen <run...@gmail.com> wrote: > > > 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 > >>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
