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