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 Mon, 11 May 2015 12:51:15 GMT
I'm fine with that: rm must have a reviewer on merges? Seem heavy for
trivial changes but alright

On Mon, 11 May 2015 14:16 Sebastien Goasguen <runseb@gmail.com> wrote:

>
> > On May 11, 2015, at 2:00 PM, Daan Hoogland <daan.hoogland@gmail.com>
> wrote:
> >
> > +1 how about my proposal to have 6 RM and demand that at least 2 agree on
> > each PR?
>
> +0.5
>
> we can say that we need two pairs of eyes to ok the PR for merge.
> no need to formally have 6 RMs ?
>
> so 1 RM (you or me) + another pair of eyes would work ?
>
> >
> > Op ma 11 mei 2015 om 09:52 schreef sebgoa <runseb@gmail.com>:
> >
> >>
> >> On May 6, 2015, at 10:59 AM, Daan Hoogland <daan.hoogland@gmail.com>
> >> wrote:
> >>
> >>> 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!
> >>>
> >>
> >> I can RM as well.
> >>
> >> How about we lock down master on wednesday ?
> >> From that point forward we only take PR into master -either you or me-
> all
> >> other direct commits to master will be reverted !!!!
> >>
> >>
> >> -sebastien
> >>
> >>
> >>
> >>> 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