Will do tomorrow On Wed, 6 May 2015 17:27 Rohit Yadav <bhais...@apache.org> wrote:
> Hi Daan, > > I've merged awsapi after it passed travisCI tests and packaging worked > (Here's a test repo without awsapi package: > http://packages.bhaisaab.org/cloudstack/nukeawsapi/). > Please go ahead with merging 4.5 on master. Let me know you've time > and bandwidth to do it otherwise I can help with that as well. > > Regards. > > On Wed, May 6, 2015 at 4:00 PM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > Fcourse > > > > > > On Wed, 6 May 2015 15:02 Sebastien Goasguen <run...@gmail.com> wrote: > >> > >> Can you sync with Rohit, who is merging the noawsapi stuff as well.. > >> > >> > 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! > >> > > >> > 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 > >> >>>>>>>>>>> > >> >>>>>>>> > >> >>>>>> > >> >>>>>> > >> >>>> > >> >>>> > >> >> > >> >> > >> > > >
