[openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

Doug Hellmann doug at doughellmann.com
Tue Jul 26 17:44:21 UTC 2016


Excerpts from Hayes, Graham's message of 2016-07-26 13:48:35 +0000:
> On 26/07/2016 14:15, Sean Dague wrote:
> > On 07/26/2016 08:51 AM, Doug Hellmann wrote:
> > <snip>
> >>
> >> Given the amount of in-progress work to address the issue you've
> >> raised, I'm not convinced we need a global rule or policy. All of
> >> the teams mentioned are working toward the goal of providing stable
> >> APIs already, and no one seems to be arguing against that goal. The
> >> teams doing the work are not dragging their feet, and a rule or
> >> policy wouldn't make the work go any faster.
> >>
> >> The directions for cross-project teams were given when the bit tent
> >> change went into effect were to "support all official teams" and
> >> definitely not "do the work for all official teams." There was also
> >> no requirement that the support be exactly equal, and it would be
> >> a mistake to try to require that because the issue is almost always
> >> lack of resources and not lack of desire.  Volunteers to contribute
> >> to the work that's needed will do more to help than a one-size-fits-all
> >> policy.
> >
> > Yes, exactly.
> >
> > Like Ihar said earlier, we get all kinds of breaks across out system all
> > the time. It's a complex system. If you look hard what you'll notice is
> > that project interactions where there are team members in common break a
> > bit less. For instance Grenade breaks Nova less than other projects.
> > oslo.versionedobjects breaks Nova less than oslo.messaging does. Why?
> > Because even with stable interfaces and tests, a lot of behavior remains
> > in flux given the patch rate on all projects. And when people understand
> > both sides of a problem, they are more likely to anticipate a problem
> > during review that no tests caught and didn't seem to change an interface.
> >
> > This isn't a thing that gets fixed with policy. It gets fixed with people.
> >
> >     -Sean
> >
> 
> If this is where all these projects are going, is a policy not a good
> way to indicate that this is how we want to work in the future?
> 
> So when the next project starts, or a team wants to move in a different
> direction we have a piece of policy that shows we feel that this is the
> way we work as a community?
> 
> I don't understand the objection to stating "this is how we should work"
> when teams are moving that way anyway.
> 
> If to do that we need to dilute the policy, so be it.
> 

I do agree that writing down our expectations is a good thing.  In
this case, I think the policy that the TC has agreed to is accurately
and sufficiently documented in the existing resolution under the
"Impact for horizontal teams" section [1].  The stewardship working
group is actively working on a set of general principles for the
TC to consider, and it may make sense to incorporate the existing
policy into that list of principles to make it easier to find.

I personally don't agree with changing the policy, or making it
"stronger" in some way, right now because I'm not convinced that
we need to treat all projects exactly the same in all cases.  It
seems like a relatively benign assumption to make, but until we
actually have an issue that would be solved by formalizing it in
policy I would prefer to avoid introducing unintended consequences
in implementations of projects brought on by layers of rules.  We
don't want any projects discriminated against, but I don't think
that's what is happening in these cases, and I think the existing
policy addresses that case.

Doug

[1] http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html#impact-for-horizontal-teams



More information about the OpenStack-dev mailing list