fuel-dev team mailing list archive

[Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>]

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
38, Lenina ave.
Kharkov, Ukraine
www.mirantis.com
www.mirantis.ru
bdobrelia@xxxxxxxxxxxx