Open Stack

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|