Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: message received from 54.191.145.13
 which is an MX secondary for dev@cloudstack.apache.org)
MIME-Version: 1.0
References: 
 <CAD97ioceytPkxC+DzZZZaAOEpOjiLm6wAT=F-XuEHcWjUPE7GQ@mail.gmail.com>
 <6D31CED9-6376-4925-8C49-A3BAB038F3E2@gmail.com>
 <CAGQtxvZxy_cXuLXVps_0Mcz2cVpcC6ec3kabU9uX92enFA8P6A@mail.gmail.com>
 <CALFpzo7gM0+A3+Y0vQtvjk9LNKVjyLiYyLe2BvrcMgyS6dthyg@mail.gmail.com>
 <CAGQtxvahoPvUMbuVLkD3-E4L6ZRywouwCM3fUFOVNn-89Dq3Tg@mail.gmail.com>
 <CALFpzo7z-UGgyqqzbvasgeeE3od5+VPY4sLvcgcscjRoEysu2g@mail.gmail.com>
 <95019686-345C-4F00-B989-1F4ACA16B5B2@gmail.com>
 <CALFpzo5Nthpvoj0b+HhmdUEpq_v1xVyq2J0PhU-oXqUW8FqRzQ@mail.gmail.com>
 <4F991649-BDF1-4CD5-8C28-B1CF4B11638E@gmail.com>
 <CAD97ioe5r9EmePxLPg+6+oO2XmqsraHA83fAxyUJxNUBGo0H8w@mail.gmail.com>
 <091B4D7F-2087-4B6E-880C-E381E91BEA6D@gmail.com>
 <CAGQtxvZa5wYdROWFsReoJe9=vhQfbDc=TdBeKfW3r5O4qhY7-A@mail.gmail.com>
 <C600E233-F253-4B9F-9D26-0A6317E90076@gmail.com>
 <CAGQtxvYN-wE2dc_xPKkiARvOZ3W+Ahe4vkDgmaYB4wq5DTrj8w@mail.gmail.com>
 <6D7F5A48-688B-4CB4-A765-91F03C4FE878@gmail.com>
In-Reply-To: <6D7F5A48-688B-4CB4-A765-91F03C4FE878@gmail.com>
From: Daan Hoogland <daan.hoogland@gmail.com>
Date: Wed, 06 May 2015 14:00:33 +0000
Message-ID: 
 <CAGQtxvZzc=cM9MXiOnxrJfvjmnxmffv78wWxHE_PbcY3XNx86g@mail.gmail.com>
Subject: Re: [DISCUSS] 4.6 release management
To: dev@cloudstack.apache.org, Rohit Yadav <bhaisaab@apache.org>
Content-Type: multipart/alternative; boundary=001a11c3ca22013bbd05156a38e6

--001a11c3ca22013bbd05156a38e6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 starti=
ng
> >> 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 nobod=
y
> >> did
> >>> for long time. +1 for the present state of Sebastien's views on thing=
s.
> >> 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 effor=
ts
> >> 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=E2=80=A6.
> >>>>
> >>>> 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 y=
ou
> >>>> 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. I=
f
> 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 i=
t
> 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 propo=
se
> >>>>>>> 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 b=
e
> >>>>>>> merges that have been tested against master before merge. This wi=
ll
> >> 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, teste=
d
> >>>>>>> against master, and merged to master). We can essentially set a
> date
> >>>>>>> and do that any time, with some advance notice that direct commit=
s
> >>>>>>> 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 hav=
e
> >> 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 abou=
t
> >>>>>> 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 whi=
ch
> >>>> 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 o=
r
> >>>> 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 thi=
nk
> >> 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=E2=80=A6
> >>>>>>>>>>>> I agree and we can even go as far as reverting fixes that ar=
e
> >>>>>>>>>>>> cherry-picked in favour of merged forward.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> IMHO, I think this would be a good step but I don=E2=80=99t=
 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 fr=
om
> >> 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=E2=80=99d branch time after time=E2=80=A6.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
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>

--001a11c3ca22013bbd05156a38e6--