Open Stack

----- Original Message -----
> From: "Li Ma" <skywalker.nick at gmail.com>
> Cc: enterprise-wg at lists.openstack.org
> 
> On Wed, Mar 4, 2015 at 1:25 AM, Stefano Maffulli <stefano at openstack.org>
> wrote:
> > On Sat, 2015-02-28 at 10:25 +0800, Li Ma wrote:
> >> Here's a situation that I discovered when I reviewed some patches in
> >> the upstream. Currently, for most of the projects, only master branch
> >> is well looked after. Even for those stable branches, backport work is
> >> not that sufficient.
> >
> > This message made me scroll the list of people maintaining the stable
> > branch: https://review.openstack.org/#/admin/groups/120,members The
> > names there seem all to have a lot of other jobs to attend too and I
> > suspect they may be overloaded already. So even if it looks like there
> > are lots of people capable of approving patches with +2+w votes, there
> > may not be enough people doing the heavy lifting to provide patches and
> > backports to stable branch.
> >
> > If stable and backports are a priority, I think it would be good to put
> > people to work on those tasks and not expect that someone else will do
> > it.
> 
> Currently, OpenStack's vision is to create private and public clouds
> [1]. When enterprise IT (private clouds) involves, I think stable
> release and backports are of higher priority than blueprints. And for
> community, LTS policy also needs to be clearer, governed and placed in
> the main page.
> 
> For this backport issue, IMO, the developer who proposes the patch
> should be in charge of backports. However, we are working with the
> master branch, maybe someone doesn't realize this patch needs to be
> backported to other stable branches or someone doesn't know about how
> this patch influences on a given stable release. BTW, there's no
> standard and mandatory procedure to check if it is necessary to
> backport or not.

Who defines what is "necessary" to backport and how many releases back? If you ask different people or organizations these questions you will likely get very different answers. You are correct in that there is no standard and mandatory procedure to check if it is necessary to backport, in fact the current guidelines work in the opposite direction. Anyone can propose a backport as long as the change meets the criteria set out in https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy.

This is not, I believe, by accident but rather a result of the fact that there is little appetite in the development community for maintaining the stable branches outside of a couple of people representing the distributions. As there are very few people actively reviewing stable branch submissions there is often a delay before they are approved (this was one of the complaints in the kilo edition of this saga: https://etherpad.openstack.org/p/kilo-relmgt-stable-branches).

> I suggest to add a plugin into gerrit review procedure. When someone
> would like to provide +w vote, he/she needs to answer one question: is
> it necessary to backport? for which stable branch? If some backport
> work still needs to be done, the workflow should not be closed (+w)
> until the related cherry-pick work is done.
> 
> [1] www.openstack.org

Somewhat related to the above, while this is simple on paper for it to have any chance of success it requires buy in from the developer community both to convince a critical mass to support implementing such a rule and to build the stable branch review teams to cope with the increased submissions (otherwise the problem just moved down the chain because instead of not being proposed to stable the changes will be proposed to stable and languish in the review queue). How do you propose incentivising the adding of this rule, answering of the question honestly (as above for many the answer to the question is going to always be no, because for them a backport is not necessary as they don't use stable branches), and reviewing of stable branch changes.

The alternative as Steffano suggests is for organizations interested in this to assign resources to (a) monitoring patch submissions for potential backports to propose (b) reviewing such proposals with a view to ultimately expanding the membership of stable-maint-core. As I noted above, for your proposal to be successful the second part of this pertaining to more stable branch reviewers is required regardless.

Thanks,

Steve