[openstack-dev] [nova] stable branches & failure to handle review backlog
Daniel P. Berrange
berrange at redhat.com
Tue Jul 29 13:13:30 UTC 2014
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.
>
> >> If we are trying to throttle down the rate of change in Havana, that
> >> totally makes sense, but we should be more active at rejecting patches
> >> if that is our current goal, not let them hang around in limbo for
> >> many months.
> >
> > Tip: to be notified in time about new backport requests, you may add
> > those branches you're interested in to watched, in Gerrit, go to
> > Settings -> Watched Projects, and add whatever you like. Then you'll
> > receive emails for each backport request.
> >
> >
> >> I'm actually unclear on who even has permission to approve patches
> >> on stable branches ? Despite being in Nova core I don't have any perm
> >> to approve patches on stable. I think it is pretty odd that we've got a
> >> system where the supposed experts of the Nova team can't approve patches
> >> for stable. I get that we've probably got people on stable team who are
> >> not in core, but IMHO we should have the stable team comprising a superset
> >> of core, not a subset.
> >
> > AFAIK stable team consists of project PTLs + people interested in stable
> > branches specifically (that got added to the team after their request).
> > Anyone can start reviewing the patches and ask to be added to the team.
> >
> > I also think it's weird that project cores don't have +2 for stable
> > branches of their projects. They do not require global +2 for all stable
> > branches though.
>
> The key reason why $PROJECT-core don't automatically get stable branch
> +2 is that the rules for accepting a patch there are VERY different from
> the rules for accepting a patch for master, and most -core people don't
> know those.
>
> We need to ensure those -core people know the stable branch acceptance
> rules before we grant them +2 there.
I think that's a really weak argument against having core team to take
part in the stable branch approval. If the rules are outlined somewhere
on the wiki anyone I know on the core team is more than capable of
reading & following them.
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 :|
More information about the OpenStack-dev
mailing list