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* <mscherbakov@xxxxxxxxxxxx
<mailto:mscherbakov@xxxxxxxxxxxx>>
Date: 2013/12/16
Subject: Re: [Fuel-dev] Process improvements revisited
To: Roman Alekseenkov <ralekseenkov@xxxxxxxxxxxx
<mailto:ralekseenkov@xxxxxxxxxxxx>>
Cc: "fuel-dev@xxxxxxxxxxxxxxxxxxx
<mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>" <fuel-dev@xxxxxxxxxxxxxxxxxxx
<mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>>
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
<ralekseenkov@xxxxxxxxxxxx <mailto:ralekseenkov@xxxxxxxxxxxx>> 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
<http://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
<bdobrelia@xxxxxxxxxxxx> 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
<manashkin@xxxxxxxxxxxx> wrote:
And do not use push, use `git review` without parameters
On Wed, Dec 11, 2013 at 5:36 PM, Miroslav Anashkin
<manashkin@xxxxxxxxxxxx> 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
<bdobrelia@xxxxxxxxxxxx> 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
<https://launchpad.net/%7Efuel-dev>
Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx
<mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~fuel-dev
<https://launchpad.net/%7Efuel-dev>
More help : https://help.launchpad.net/ListHelp
