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.);

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

- 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

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

- 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

- 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

[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<mailto: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+CloudStack
 
<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.

Regards,
Remi


Regards,
Rohit Yadav
Software Architect, ShapeBlue


[cid:9DD97B41-04C5-45F0-92A7-951F3E962F7A]


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.

Reply via email to