I’m back online and will continue working on this as soon as I worked through the many mails ;-)
Happy to be your RM together with Rajani! Regards, Remi On 17 Jul 2015, at 17:04, sebgoa <run...@gmail.com<mailto:run...@gmail.com>> wrote: Finally read the thread, It seems to me that a way forward is to have Remi and Rajani RM 4.6 (which is currently master). The two of them can discuss and start RMing 4.6 (PR merge etc) and then we can iterate on the wiki release scenario. @Remi @Rajani, would that work for you and you ready to get started ? -sebastien On Jul 10, 2015, at 8:17 PM, Daan Hoogland <daan.hoogl...@gmail.com<mailto:daan.hoogl...@gmail.com>> wrote: I hate to be as opiniated as I am but here it comes ;) On Fri, Jul 10, 2015 at 7:39 PM, Rohit Yadav <rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> wrote: While I like the ideas generally [1], some concerns and observations that I wish could be considered; - active contributor crunch: we don’t have large number of active people working towards testing, fixing bugs and release, and reviewing/merging PRs on *master*; this affects the agility of any process or workflow we want to put in, or expect resolution in a certain window (3-5 days etc.); This is a very valid concern. We are a large community but not in any way big enough. One approach is to let no backporting of bugfixes happen! it sound contrary to some of your points but I think it is actually a mitigation (see below). - diverse interests: our user-base may not necessarily want to upgrade to newer version of CloudStack even if they can proved to be quite stable; in-fact commercially some of us are paid to maintain stable branches and support users who are still on 4.2/4.3/4.4/4.5 etc; based on my experience, a typical enterprise users usually stick with a version (that works for them) for at least 6 months, while smb user or in-house consumers are quite agile who may upgrade as quickly as when new releases are made; User do go for bug fixes and are not concerned with any backwards compatible changes to functionality. If we guard against those, point releases are replaced by the minors and people can be as 'sticky' as they want. In the end it is a matter of naming and discipline. Of course we need to sell our policy. - diverse branching/merging workflow usage and understanding: the bugfix workflow may not be acceptable (to go on master first), a lot of people have their own way of branching/merging in their organisations that affect how they do it in the the project I do not think it is. If you want something fixed you should fix it on the oldest version it needs fixing on. No backporting at all. this only mystifies our git tree and prohibits good administration. Bug-fixes can be merged forward and whether anyone has one of infinite other possible release management schemes internally should not influence the way they work on this project. - waiting time on new changes: since we don’t have large number of active testers and developers who can fix bugs rapidly, freezing master and doing the release may take a lot of time (unless if we can put a hard deadline or have some schedule to support that?), in which case new features and refactoring work will have to lay hanging (and some rebase/code-rework may be needed later when they are merged, when master is open) lso very valid. No freeze, just release candidates would be a solution to that. One point in time is proposed as candidate and voted on. if it goes it goes, if it doesn't there will be new chances in the near future. We do depend on good quality control on master for this. - release risk: after a release x.y.0 is made and since master can receive new features, refactoring work; the next x.y.1 can potentially add more regressions due to those new features and refactoring/re-architectural work I don't agree here; any x.y.1 will be on a branch other then master. - release maintenance and support demands: historically there has been an assumed or known stable release that is fairly tested in the wild and has built trust due to usage by users (through meetups, users ML, customer interactions etc), in the past those versions were 4.2.1 then 4.3.1/4.3.2, now based on my experience the last stable release is 4.5.1 You know we don't agree on 4.4 vs 4.5 and I don't want to fight that fight here and now but how is this a concern either way? Any minor can have point releases following it if needed. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack On 02-Jul-2015, at 5:16 pm, Remi Bergsma <r...@remi.nl> wrote: Hi all, We already agreed contributions should always go via a PR and require two LGTM’s before we merge. Let me propose the next step on how I think we should do release management for 4.6 and on. I talked to several people over the past weeks and wrote this wiki article: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudSta ck < https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack If you like this way of working, I volunteer to be your RM :-) Like folks suggested earlier, it would be nice to work on this with multiple people. So, feel free to join. Maybe @dahn @bhaisaab and/or others are willing to teach me some of their tricks. -- Daan
