cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: [DISCUSS] 4.6 release management
Date Mon, 11 May 2015 12:13:06 GMT

> 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
View raw message