Hi guys, I hope that’s not too late to react on this one.
Having 6 RMs seems a bit too much for me. For PRs containing a few lines of code, just bug fixes or changing maven files, python, sh, etc it might be simple and quick. However, if we get a PR with +30 commits and 10k lines added, it gets really difficult to get the community to test/review the PR. So, for 2 people to go over it is already taking too long to get the code imagine, now imagine 4 or 6. Rohit has done an excellent job in looking into the PRs, commenting on them and some times testing as well. But there are things that cannot simply get him, or perhaps other guys, to test properly a PR; having time and environment as the main reasons. I would say that in case we have a PR that contains: 1. Documentation on the Apache CS Wiki 2. Unit Tests (a lot of them, minimum 70% for the code changed) 3. Marvin Test Results report - test_routers, test_vpc_routers, test_vm_life_cycle, test_account, at least. Should be given priority and get less RMs involved in order to speed up our development/release processes. Unless, of course, the people would have time to look into the PR immediately. What do you think? Cheers, Wilder On 11 May 2015, at 15:54, Rohit Yadav <rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> wrote: On 11-May-2015, at 2:51 pm, Daan Hoogland <daan.hoogl...@gmail.com<mailto:daan.hoogl...@gmail.com>> wrote: I'm fine with that: rm must have a reviewer on merges? Seem heavy for trivial changes but alright On Mon, 11 May 2015 14:16 Sebastien Goasguen <run...@gmail.com<mailto:run...@gmail.com>> wrote: On May 11, 2015, at 2:00 PM, Daan Hoogland <daan.hoogl...@gmail.com<mailto:daan.hoogl...@gmail.com>> wrote: +1 how about my proposal to have 6 RM and demand that at least 2 agree on each PR? +0.5 we can say that we need two pairs of eyes to ok the PR for merge. no need to formally have 6 RMs ? so 1 RM (you or me) + another pair of eyes would work ? I’ve been doing PR reviews as a habit, happy to chip-in as a co-pilot. Op ma 11 mei 2015 om 09:52 schreef sebgoa <run...@gmail.com<mailto:run...@gmail.com>>: On May 6, 2015, at 10:59 AM, Daan Hoogland <daan.hoogl...@gmail.com<mailto: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<mailto: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<mailto: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<mailto:run...@gmail.com>>: On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pdion...@apache.org<mailto: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<mailto:run...@gmail.com>> wrote: On Apr 29, 2015, at 9:49 PM, Marcus <shadow...@gmail.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto:daan.hoogl...@gmail.com>> wrote: On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen < run...@gmail.com<mailto:run...@gmail.com>> wrote: On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion < pd...@cloudops.com<mailto: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 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com> Blog: bhaisaab.org<http://bhaisaab.org/> | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
