Guys, I came across your conversation accidentally and I think I have my two cents to add to it. I went through the hell of branching strategy set up in my previous company - I guess I have something useful to say.
First of all, I see, when you have a bugfix for 3.2.1 you do two commits one to master and one to 3.2 fixes branch, you don't event cherry pick - this is lame. Fixes should be introduced to the oldest branch and then this branch should be merged into all branches where this commit should go to. I would recommend to review these two documents before introducing any new branching model: http://nvie.com/posts/a-successful-git-branching-model/ https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html Thanks, Victor. ---------- Forwarded message ---------- From: Mike Scherbakov <[email protected]> Date: 2013/12/16 Subject: Re: [Fuel-dev] Process improvements revisited To: Roman Alekseenkov <[email protected]> Cc: "[email protected]" <[email protected]> We did. Bugs can be picked up by anyone to help. Also, please take a look at bugs with Fuel Python Team or UI Team assignees, it is simply a group - so you can also take a look there and re-assign on yourself. Regards, On Mon, Dec 16, 2013 at 9:50 PM, Roman Alekseenkov < [email protected]> wrote: > Team, > > Thank you for the call. Let's keep doing this. > > Mike, > > As discussed, please unset assignee for the bugs your team is not actively > working on. So they can be picked up by the US engineering team. > > Thanks, > Roman > > > On Monday, December 16, 2013, Mike Scherbakov wrote: > >> Dmitry, >> thank you for bringing this up in a constructive manner with proposed >> changes. With the additional stuff, discussed on the call - let me provide >> our agreements. >> >> Before going into every point, we agreed that we are following OpenStack >> development model and would like to stick with it as far as we can, and >> reuse all the existing tools, such as OpenStack Infra, Gerrit, >> github.com/stackforge, launchpad. The closer we are with OpenStack >> flows, the easier life for both newcomers into Fuel from OpenStack >> community and Fuel developers. >> >> *1. Branch management for maintenance releases* >> >> - We had 3.2-fixes branch created, it worked good unless minor issues >> with a few forgotten commits which were not proposed to master at the same >> time as they were proposed to master. >> - We will create stable/4.0 branch right before the code freeze >> announcement, which will include all required links / information >> - git whatchanged can not be used to compare branches: it sees merges >> as another commits. Current situation is all required fixes were proposed >> and merged to master from 3.2-fixes - verified by Dmitry Pyzhov >> (fuel-main, >> fuel-astute), Vladimir Kuklin (fuel-library) and Tatyana Leontovich >> (fuel-ostf) >> - I fully agree that core reviewers must not accept code into stable >> branch unless it is merged into master or patchset has a description why >> it >> should be only in stable branch. In the long run, we need to see if it is >> possible to configure Jenkins to automatically "-1" such requests to >> stable >> branches. >> - Let's keep following existing workflows as far as we can go with >> them: >> https://wiki.openstack.org/wiki/StableBranch >> https://wiki.openstack.org/wiki/GerritJenkinsGit >> >> *2. Management and code review of feature development branches* >> >> - > reject changes that are too large and/or contain messy revision >> history - all agree on this. All core reviewers - please keep an >> attention. >> - Code is unreviewed for a long time >> As we moved away from Kanban board - it is harder and harder for >> leads to keep an eye on every patchset. Instead, as we agreed - let's >> evangelize to follow another approach - as a developer, my work is not >> complete unless my code is merged into master and bug / blueprint is >> closed. So, team lead's job here is to control if developers push hard >> enough to make their code reviewed and merged. Dear Team Leads, please >> take >> a careful look at those patchsets which are not updated for more than a >> few >> days - and ping developers. Dear Developers, please don't wait to be >> pinged >> or punished, don't leave your code for abandonment :) >> - > when going through reviews, start with fixes for critical bugs - >> With you here, my ++ >> - > Don't merge a review request if there's an older review request >> that can also be merged - With you here too, ++ >> >> >> *3. Bugs triage* >> My suggestion is simply to follow: >> https://wiki.openstack.org/wiki/Bugs and >> https://wiki.openstack.org/wiki/BugTriage. >> I have to admit though that some additional notes are required to make >> it easy to set appropriate status, and may be for triaging as well. For >> example, if one OSTF test fails because of test itself - it should never be >> Critical, but if whole OSTF doesn't work - I believe it should. As we use >> OSTF for OpenStack deployment verification, including system tests, we can >> easily miss the point when we break something else. >> Please do not hesitate to propose additions to the links above specific >> for Fuel only. >> >> >> Some other questions raised: >> *WIP branches *should* be maintainable despite on anything* >> I believe we should not have such branches despite on anything :) Let's >> discuss every situation when it is needed, and see if there is anything we >> can do. >> I do not want to see such branches, as it will be always hard to merge >> and review later. So, if possible, it should be split on several pieces >> which could be merged independently, even if many parts are stubbed / not >> even enabled (with corresponding comments of course). >> >> *Core reviewers* >> As we agreed on the core reviewers/management meeting - Dmitry Borodaenko >> is added to the team of core reviewers. Congrats! :) >> >> Bogdan D. - on your question about branches creation, please talk to >> Dmitry Pyzhov. >> >> Thanks! >> >> >> On Wed, Dec 11, 2013 at 5:55 PM, Bogdan Dobrelya >> <[email protected]>wrote: >> >> On 12/11/2013 03:42 PM, Vladimir Kuklin wrote: >> >> or git review <branch_name> if you are requesting change to another >> branch than master >> >> Yes, I already have a forks for most of main fuel repos, I use them for >> storing my WIP branches, because I cannot create any branches at main repo, >> and >> *that* was the 1st subject of discussion for long running R & D >> activities. >> And the 2nd subject was addressed to "long-lived feature branches with >> many commits and thousands of lines" >> >> (Yet another thing that everyone seems to agree on is that huge >> >> long-lived feature branches with many commits and thousands of lines >> worth of changes are evil and dangerous. Luckily, the move to Gerrit >> will make it hard enough to maintain and merge multi-commit branches, >> and will push people towards committing and merging changes in smaller >> self-sufficient chunks.) >> >> So, I was initially asking to elaborate, what if such WIP branches >> *should* be maintainable despite on anything, and how (what is the best >> practice for now?) >> >> >> >> >> On Wed, Dec 11, 2013 at 5:37 PM, Miroslav Anashkin < >> [email protected]> wrote: >> >> And do not use push, use `git review` without parameters >> >> >> On Wed, Dec 11, 2013 at 5:36 PM, Miroslav Anashkin < >> [email protected]> wrote: >> >> Please fork stackforge repo to your account first and use the forked >> version >> >> >> On Wed, Dec 11, 2013 at 4:57 PM, Bogdan Dobrelya >> <[email protected]>wrote: >> >> On 12/11/2013 01:35 PM, Oleg Gelbukh wrote: >> >> Looks like fuel.config already have this configuration actually: >> >> >> https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/gerrit/acls/stackforge/fuel.config#n5 >> >> Did you check if you actually can create a branch? >> >> Yes, >> >> Mike Scherbakov >> #mihgen >> > -- Mike Scherbakov #mihgen -- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
