+1 how about my proposal to have 6 RM and demand that at least 2 agree on each PR?
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 > >>>>>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
