I just did a test merge: ~/cloudstack/cloudstack (master)> git merge --no-ff --edit -s ours 4.5 gives a clean merge of the last bits from 4.5 and merges without conflicts
I will rerun a merge and push if the RC passes Op wo 6 mei 2015 om 10:59 schreef Daan Hoogland <daan.hoogl...@gmail.com>: > 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! > > 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 >> >>>>>>>>> >> >>>>>> >> >>>> >> >>>> >> >> >> >> >> >>
