Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 29/07/14 18:12, Daniel P. Berrange wrote:
> On Tue, Jul 29, 2014 at 08:30:09AM -0700, Jay Pipes wrote:
>> On 07/29/2014 06:13 AM, Daniel P. Berrange wrote:
>>> On Tue, Jul 29, 2014 at 02:04:42PM +0200, Thierry Carrez
>>> wrote:
>>>> Ihar Hrachyshka a écrit : At the dawn of time there were no
>>>> OpenStack stable branches, each distribution was maintaining
>>>> its own stable branches, duplicating the backporting work. At
>>>> some point it was suggested (mostly by RedHat and Canonical
>>>> folks) that there should be collaboration around that task, 
>>>> and the OpenStack project decided to set up "official" stable
>>>> branches where all distributions could share the backporting
>>>> work. The stable team group was seeded with package
>>>> maintainers from all over the distro world.
>>>> 
>>>> So these branches originally only exist as a convenient place
>>>> to collaborate on backporting work. This is completely
>>>> separate from development work, even if those days backports
>>>> are often proposed by developers themselves. The stable
>>>> branch team is separate from the rest of OpenStack teams. We
>>>> have always been very clear tht if the stable branches are no
>>>> longer maintained (i.e. if the distributions don't see the
>>>> value of those anymore), then we'll consider removing them.
>>>> We, as a project, only signed up to support those as long as
>>>> the distros wanted them.
>>>> 
>>>> We have been adding new members to the stable branch teams
>>>> recently, but those tend to come from development teams
>>>> rather than downstream distributions, and that starts to bend
>>>> the original landscape. Basically, the stable branch needs to
>>>> be very conservative to be a source of safe updates --
>>>> downstream distributions understand the need to weigh the
>>>> benefit of the patch vs. the disruption it may cause. 
>>>> Developers have another type of incentive, which is to get
>>>> the fix they worked on into stable releases, without
>>>> necessarily being very conservative. Adding more -core people
>>>> to the stable team to compensate the absence of distro
>>>> maintainers will ultimately kill those branches.
>>> 
>>> The situation I'm seeing is that the broader community believe
>>> that the Nova core team is responsible for the nova stable
>>> branches. When stuff sits in review for ages it is the core
>>> team that is getting pinged about it and on the receiving end
>>> of the complaints the inaction of review.
>>> 
>>> Adding more people to the stable team won't kill those
>>> branches. I'm not suggesting we change the criteria for
>>> accepting patches, or that we dramatically increase the number
>>> of patches we accept. There is clearly alot of stuff proposed
>>> to stable that the existing stable team think is a good idea -
>>> as illustrated by the number of patches with at least one +2
>>> present. On the contrary, having a bigger stable team comprises
>>> all of core + interested distro maintainers will ensure that
>>> the stable branches are actually gettting the patches people
>>> in the field need to provide a stable cloud.
>> 
>> -1
>> 
>> In my experience, the distro maintainers who pioneered the stable
>> branch teams had opposite viewpoints to core teams in regards to
>> what was appropriate to put into a stable release. I think it's
>> dangerous to populate the stable team with the core team members
>> just because of long review and merge times.
> 
> Sure there was some debate about what criteria were desired
> acceptance when stable trees were started. Once the criteria are
> defined I don't think it is credible to say that people are
> incapable of following the rules. In the unlikely event that people
> were to willfully ignore the agreed upon rules for stable tree,
> then I'd not trust them to be part of a core team working on any
> branch at all. With responsibility comes trust and an acceptance to
> follow the agreed upon processes.

Still, it's quite common to see patches with no cherry-pick info, or
Conflicts section removed, or incorrect Change-Id being approved and
pushed. It's also common for people to review backports as if they are
sent against master (with all nit picking, unit test changes
requested, no consideration for stable branch applicability...)

> 
> Regards, Daniel
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJT2LfQAAoJEC5aWaUY1u570woIAME9gwi7MlgqhXnxMwbnn+fv
Exrh3zSXfCvxQ76F5z0CVxu04bItdI4ZfYOU+/Emxx+ay0evGhHPP5jjvUYhsbED
h6Nqf/yefLQZkhuwKTNyiV3FObOsPG+Cu6yAYn8y/eUyGypQfx5oXLSof+GkzMhf
bMtVdxJawfWyrUJjuQpaAbZbpGzCDjqoBsZK+28RMxraBJDsz2qKpzrUp5xH71Wb
NuyKSzM5/wsbW6NtUeRESJ7HtvT8kcl1CbYAkTvbjpY4+zN2Xe63Tf62cKC30eli
XPP3feaPPaudUznfRLhVqRB1Yel/f0+wyj7p9NnO6cASOx2OO1O4GCI3+E2ElnY=
=hP7m
-----END PGP SIGNATURE-----