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 >>>>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >>
