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.
Distros can and should have more people participating in the stable
teams -- as should non-distro folks that deploy and care about
non-master deployments.
If core team members are getting pinged about certain reviews on stable
branches, they should direct the pinger to the stable team members.
Just my 2 cents,
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
