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 <run...@gmail.com>: > > On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pdion...@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 <run...@gmail.com> > > wrote: > > > >> > >>> On Apr 29, 2015, at 9:49 PM, Marcus <shadow...@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 <run...@gmail.com > > > >> wrote: > >>>> > >>>>> On Apr 18, 2015, at 8:36 AM, Marcus <shadow...@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.hoogl...@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" <shadow...@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.hoogl...@gmail.com> > >>>>>>> wrote: > >>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen < > >> run...@gmail.com> > >>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion < > pd...@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 > >>>>>>> > >>>> > >> > >> > >
