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 17:38:53 GMT
Will do tomorrow

On Wed, 6 May 2015 17:27 Rohit Yadav <bhaisaab@apache.org> wrote:

> Hi Daan,
>
> I've merged awsapi after it passed travisCI tests and packaging worked
> (Here's a test repo without awsapi package:
> http://packages.bhaisaab.org/cloudstack/nukeawsapi/).
> Please go ahead with merging 4.5 on master. Let me know you've time
> and bandwidth to do it otherwise I can help with that as well.
>
> Regards.
>
> On Wed, May 6, 2015 at 4:00 PM, Daan Hoogland <daan.hoogland@gmail.com>
> wrote:
> > Fcourse
> >
> >
> > On Wed, 6 May 2015 15:02 Sebastien Goasguen <runseb@gmail.com> wrote:
> >>
> >> Can you sync with Rohit, who is merging the noawsapi stuff as well..
> >>
> >> > 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!
> >> >
> >> > 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