cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS] 4.6 release management
Date Wed, 06 May 2015 08:59:20 GMT
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!

Op wo 6 mei 2015 om 09:47 schreef sebgoa <runseb@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.hoogland@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 <runseb@gmail.com>:
> >
> >>
> >> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pdion891@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 <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