--
Best regards,
Oleg Gelbukh
On Wed, Dec 11, 2013 at 1:02 PM, Bogdan Dobrelya
<bdobrelia@xxxxxxxxxxxx <mailto:bdobrelia@xxxxxxxxxxxx>> wrote:
Hello.
On 12/10/2013 09:14 PM, Dmitry Borodaenko wrote:
All,
We still have a few pain points left in our
development process that I
think are easy to fix with a bunch of simple rules.
I think releasing
4.0 will be less painful if we try to address these.
1. Branch management for maintenance releases
We already had this discussion during 3.2.1 release
cycle, and agreed
to follow the approach that is in line with what
OpenStack and most
other free software projects are following. Still, I
think we should
do better at actually following the process we
agreed to.
To see how good we were at following it for 3.2.1,
open two terminal
windows and run:
git whatchanged 3.2..3.2-fixes
git whatchanged 3.2..master
and for each commit in 3.2-fixes, try to find a
matching fix in
master. Last time I checked there were still many
cases where bugfixes
were merged to 3.2-fixes before (or even without)
merging them to
master. Did anyone actually check that we're not
missing any important
fixes from 3.2.1 in 4.0?
We should create a new stable/4.0 branch as soon as
4.0 code freeze is
announced (ideally, the announcement itself should
direct committers
to the new branch). Reviewers should REJECT all
commits to stable/4.0
that have not been merged into master, unless a
justification is
provided in the COMMIT MESSAGE.
Can Jenkins help us by -1 such patches?
I.e. Jenkins could put -1 to any patch targeted for
non-master, unless its commits were found in master.
2. Management and code review of feature development
branches
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.
That should we do for long running researches, such as
HA improvements
(started at 3.1, targeted to 4.1 only), or torrent based
provisioning?
Should we melt down hundreds of commits into a single
patch in WIP branch,
before submitting new feature to review?
A recent negative example is the fuel-library pull
request #911 that
has merged 104 duplicate commits from ancient
alternative history into
master, instead of simply rebasing a single commit.
The only way to
prevent something like this from happening is to
summarily reject
changes that are too large and/or contain messy
revision history.
Jenkins could come to help here as well. E.g. -1, if any
commit in PR are
already present in target branch's history.
The other side of the same problem is holding back
small reasonable
changes for too long, placing unnecessary burden on
authors to keep
rebasing their change on top of other changes that
got merged earlier.
For example, my own fuel-docs pull request #67 sat
unreviewed for a
week only to be obsoleted by the move of the repo to
StackForge (after
being obsoleted couple more times by changes that
were merged ahead of
it). I suspect most other developers had similar
experiences. On top
of obvious frustration, holding a change back tempts
the author to
keep piling changes onto the same request instead of
creating a new
review request on top of updated master for their
next set of changes.
To use the same example, most of the third commit on
#67 should really
have been a separate pull request.
The fix is once again rather obvious: when going
through reviews,
start with fixes for critical bugs, then go through
remaining reviews
starting with the least recently updated ones. Don't
merge a review
request if there's an older review request that can
also be merged.
I'm using this link to see all our outstanding
review requests:
https://review.openstack.org/#/q/status:open+project:^stackforge/fuel-.*,n,z
Right now I see that there are review requests that
have +1 from CI
and from reviewers (meaning they can be merged)
sitting unchanged
since Nov 25, and a few unreviewed requests going as
far back as Nov
3. We shouldn't have a request sit untouched by an
approver for more
than a week, let alone a month. If there's a any
reason you don't want
to merge it, give it -1 and explain. Otherwise,
there's no reason not
to give it +2. If you have time to review and merge
a newer request,
you have time for that older one, too.
3. Bugs triage
Moving our bug tracking to public launchpad was an
important step
towards opening up our development process, now we
should improve
visibility of our bugs triage and release management
processes. In
addition to announcing target release dates, we
should also have well
defined release criteria (for example, no critical
bugs affecting the
upcoming release, no more than 5 bugs with high
importantce, etc.),
and documented rules on how to set importance of a
bug. We don't have
to be rigid and beaurocratic about it, but having
documented criteria
will help all participants of the process prioritize
their own work
and understand how it fits into the state of the
whole project. It
will also help avoid situations like missing an
important bugfix in a
release, by forcing us to review priorities of all
open bugs before
announcing a release.
--
Best regards,
Bogdan Dobrelya,
Researcher TechLead, Mirantis, Inc.
+38 (066) 051 07 53
Skype bogdando_at_yahoo.com <http://bogdando_at_yahoo.com>
38, Lenina ave.
Kharkov, Ukraine
www.mirantis.com <http://www.mirantis.com>
www.mirantis.ru <http://www.mirantis.ru>
bdobrelia@xxxxxxxxxxxx <mailto:bdobrelia@xxxxxxxxxxxx>
--
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
