Open Stack

Excerpts from Hayes, Graham's message of 2016-07-26 18:16:16 +0000:
> On 26/07/2016 18:47, Doug Hellmann wrote:
> > 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.
> 
> Sure, I know the work they are doing - this has been bouncing around
> my PC for a bit before I had any knowledge of what the plans were there.
> 
> > 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
> 
> This is the crux of the debate.
> 
> Are all projects equal?

According to our current policy, all projects are equal in the sense
that cross-project teams must support them. They are not equal in
that the level of support given, and criteria for choosing that
level of support, is left up to the cross-project teams.

> 
> If they are not, I will be disappointed, but we should then move to
> define this in-equality, and state who is in, and who is out.

This is not an in-or-out distinction. It's a matter of resources
available to support teams directly, or not. A few examples:

* The documentation team has drawn a line for which projects
  are included in the tutorial-driven installation guide they are
  writing.  Other teams are able to write their own installation
  guides, or even collaborate to create joint guides.

* The release team formerly had a special tag that we used to
  indicate which project teams we were managing. With the increasing
  automation, we have expanded that list of projects significantly.

* The TC has directed the QA team to take tests into the Tempest
  tree when those tests are needed for DefCore. Any other decisions
  about what tests live in-tree or out is up to the QA team.

> In some ways we are back to the stackforge vs integrated situation,
> but unlike then we have no frame of reference for how a project would
> become more equal.
> 
> If projects have difficulty getting into top level docs (for example)
> it is more difficult to grow adoption, which would let them into
> top level docs, which would help adoption ...
> 
> > seems like a relatively benign assumption to make, but until we
> > actually have an issue that would be solved by formalizing it in
> 
> I think that we have one. I could be wrong (it happens), but I think
> this is a problem, and waiting for something bigger to happen, then
> having the existential debate about what OpenStack is (again) causes
> issues that could be dealt with to grow. (See Golang discussion).

All of the examples presented so far have been addressed as work
"in progress" and not refusals of assistance.  What specific issue
do you have with a team refusing to assist you in accomplishing
something that is under their purview?

> 
> > 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.
> 
> And I disagree - I think we need it to be more explicit.

Is there discrimination happening?

Doug

> 
> > Doug
> >
> > [1] http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html#impact-for-horizontal-teams
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>