cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Luc Dion <pdion...@apache.org>
Subject Re: [DISCUSS] 4.6 release management
Date Thu, 30 Apr 2015 22:52:13 GMT
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 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!

Marcus: are you preparing a proposal on this? wiki page? I can help

Seb: doesn't the vote would confirm the consensus?

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 <runseb@gmail.com>
wrote:

>
> > On Apr 29, 2015, at 9:49 PM, Marcus <shadowsor@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 <runseb@gmail.com>
> wrote:
> >>
> >>> On Apr 18, 2015, at 8:36 AM, Marcus <shadowsor@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.hoogland@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" <shadowsor@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.hoogland@gmail.com>
> >>>>> wrote:
> >>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
> runseb@gmail.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pdion@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
> >>>>>
> >>
>
>

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