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