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 Wed, 06 May 2015 13:00:11 GMT
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
View raw message