[openstack-dev] [all] The future of the integrated release
ihrachys at redhat.com
Wed Aug 13 12:22:17 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 13/08/14 14:07, Daniel P. Berrange wrote:
> On Wed, Aug 13, 2014 at 12:55:48PM +0100, Steven Hardy wrote:
>> On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange
>>> On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
>>>> That said, I entirely agree with you and wish efforts to
>>>> stabilize would take precedence over feature work.
>>> I find it really contradictory that we have such a strong
>>> desire for stabilization and testing of our code, but at the
>>> same time so many people argue that the core teams should have
>>> nothing at all todo with the stable release branches which a
>>> good portion of our users will actually be running.
>> Does such an argument actually exist? My experience has been
>> that stable-maint folks are very accepting of help, and that it's
>> relatively easy for core reviewers with an interest in stable
>> branch maintenance to offer their services and become
>> stable-maint core:
> There are multiple responses to my mail here to the effect that
> core teams should not be involved in stable branch work and leave
> it upto the distro maintainers unless individuals wish to
doesn't indicate that stable maintainers' team is not willing to
get help from core developers. Any core can easily step in and ask for
+2 permission for stable branches, it should not take much time to get
it. Granting +2 should mean that the new member has read and
understood stable branch maintainership procedures (which are short
>>> By ignoring stable branches, leaving it upto a small team to
>>> handle, I think we giving the wrong message about what our
>>> priorities as a team team are. I can't help thinking this
>>> filters through to impact the way people think about their work
>>> on master.
>> Who is ignoring stable branches? This sounds like a project
>> specific failing to me, as all experienced core reviewers should
>> consider offering their services to help with stable-maint
>> I don't personally see any reason why the *entire* project core
>> team has to do this, but a subset of them should feel compelled
>> to participate in the stable-maint process, if they have
>> sufficient time, interest and historical context, it's not "some
>> other team" IMO.
> I think that stable branch review should be a key responsibility
> for anyone on the core team, not solely those few who volunteer for
> stable team. As the number of projects in openstack grows I think
> the idea of having a single stable team with rights to approve
> across any project is ultimately flawed because it doesn't scale
> efficiently and they don't have the same level of domain knowledge
> as the respective project teams.
Indeed, stable maintainers sometimes lack full understanding of the
proposed patch. Anyway, if a patch is easy and it has a clear
description in its commit message and Launchpad, it's usually easy to
determine whether it's applicable for stable branches.
Yes, sometimes a stable maintainer is not able to determine if a patch
should really go into stable; in that case core developers should be
asked to vote on the patch. In most cases though, it's generally
assumed that the patch contents are ok (they were already merged in
master, meaning, core developers already voted +2 on it before), and
there is no real need for special attention from core developers (that
are usually busy with ongoing work in master).
Note: there are sometimes patches that belong to stable branches only.
In those cases, stable maintainers should not be the ones to decide
whether the patch is going into the tree, because no due review ran
for the patch in master before.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
-----END PGP SIGNATURE-----
More information about the OpenStack-dev