cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <>
Subject Re: [DISCUSS] 4.6 workflow
Date Sun, 15 Mar 2015 12:36:34 GMT
Hi pierre-Luc,

Thanks for bringing this up.
The release process indeed needs discussion and action.

I agree to your suggestions. Few changes
1. no direct commits even for minor, not even fixing typo. (the definition
of minor differs from person to person and it again brings us back to the
same situation)
2. I dont think fast simulator is ready. Check the last message on the
thread you sent.

It would be better to get github jenkins gate ready(we dont have date or
expected time of this yet). If any help is needed in this effort, we should
work on this first than 4.6

It would help to publish the tentative release dates. so that, developers
can target feature merges/bug fixes.

In addition to this, I think we should also discuss the git workflow again.
merge to higher releases(atleast 4.6 to master) and stop cherry picking.


On Fri, Mar 13, 2015 at 5:50 PM, Pierre-Luc Dion <> wrote:

> Over the winter there was a Quality Improvement Initiative that was looking
> at how to make contribution to CloudStack easier and improve quality of the
> product. Basically it was a lot of discussion [2] about CI and how to use
> GIT,...
> It also look like github pull request as became quite popular, we almost
> have too much ressource into our jenkins system.  So, why not leverage this
> for the next coming release, ACS460?
> During the QA period of 4.4.0 Daan, was doing the Release manager and
> enforce the use of merge request from branches instead of direct commit
> into 4.4 branch, I think it worked well and help knowing what endup into
> hotfixe releases (4.4.1,4.4.2).
> So, I'd like to propose to change few things on how we contribute for 4.6
> releases.
> 1. emphasis github pull request, merge request, no direct commit into 4.6
> branch unless it's minor changes.
> 2. improve CI, start using the fastsimulator [1] on pull request, maybe
> some kind of gated commit [3].
> 3. test this workflow.
> Since master branch already contain a lot of new features ready to be
> tested and used, I'm wondering if we could also speedup the release
> process. Instead of waiting for all features to be ready to do RC of 4.6.0,
> release 4.6.0 without incomplete features, and as they are ready adding
> them into 4.6.1, 4.6.2.
> Please comment :-)
> [1]
> [2]
> [3]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message