Hi Thierry, thanks for the reply. Comments inline. :)
On 08/20/2014 06:32 AM, Thierry Carrez wrote:
Jay Pipes wrote:
[...] If either of the above answers is NO, then I believe the
Technical Committee should recommend that the integrated project be
removed from the integrated release.
HOWEVER, I *also* believe that the previously-integrated project
should not just be cast away back to Stackforge. I think the
project should remain in its designated Program and should remain
in the openstack/ code namespace. Furthermore, active, competing
visions and implementations of projects that address the Thing the
previously-integrated project addressed should be able to apply to
join the same Program, and *also* live in the openstack/
namespace.
All of these projects should be able to live in the Program, in
the openstack/ code namespace, for as long as the project is
actively developed, and let the contributor communities in these
competing projects *naturally* work to do any of the following:
* Pick a best-of-breed implementation from the projects that
address the same Thing * Combine code and efforts to merge the good
bits of multiple projects into one * Let multiple valid choices of
implementation live in the same Program with none of them being
"blessed" by the TC to be part of the integrated release
That would work if an OpenStack Program was just like a category
under which you can file projects. However, OpenStack programs are
not a competition category where we could let multiple competing
implementations fight it out for becoming "the" solution; they are
essentially just a team of people working toward a common goal,
having meetings and sharing/electing the same technical lead.
I'm not convinced you would set competing solutions for a fair
competition by growing them inside the same team (and under the same
PTL!) as the current mainstream/blessed option. How likely is the
Orchestration PTL to make the decision to drop Heat in favor of a
new contender ?
I don't believe the Programs are needed, as they are currently
structured. I don't really believe they serve any good purposes, and
actually serve to solidify positions of power, slanted towards existing
power centers, which is antithetical to a meritocratic community.
Furthermore, the structures we've built into the OpenStack community
governance has resulted in perverse incentives. There is this constant
struggle to be "legitimized" by being included in a Program, incubated,
and then included in the integrated release. Projects, IMO, should be
free to innovate in *any* area of OpenStack, including areas with
existing integrated projects. We should be more open, not less.
I'm also concerned with making a program a collection of competing
teams, rather than a single team sharing the same meetings and
electing the same leadership, working all together. I don't want the
teams competing to get a number of contributors that would let them
game the elections and take over the program leadership. I think such
a setup would just increase the political tension inside programs,
and we have enough of it already.
By prohibiting competition within a Program, you don't magically get rid
of the competition, though. :) The competition will continue to exist,
and divisions will continue to be increased among the people working on
the same general area. You can't force people to get in-line with a
project whose vision or architectural design principles they don't share.
If we want to follow your model, we probably would have to dissolve
programs as they stand right now, and have blessed categories on one
side, and teams on the other (with projects from some teams being
blessed as the current solution).
Why do we have to have "blessed" categories at all? I'd like to think of
a day when the TC isn't picking winners or losers at all. Level the
playing field and let the quality of the projects themselves determine
the winner in the space. Stop the incubation and graduation madness and
change the role of the TC to instead play an advisory role to upcoming
(and existing!) projects on the best ways to integrate with other
OpenStack projects, if integration is something that is natural for the
project to work towards.
That would leave the horizontal programs like Docs, QA or Infra,
where the team and the category are the same thing, as outliers again
(like they were before we did programs).
What is the purpose of having these programs, though? If it's just to
have a PTL, then I think we need to reconsider the whole concept of
Programs. We should not be putting in place structures that just serve
to create centers of power. *Projects* will naturally find/elect/choose
not to have one or more technical leads. Why should we limit entire
categories of projects to having a single Lead person? What purpose does
the role fill that could not be filled in a looser, more natural
fashion? Since the TC is no longer composed of each integrated project
PTL along with elected reps, there is no longer a need, IMO, to restrict
the number of project leads by having Program Technical Leads.
Finally, I'm slightly concerned with the brand aspect -- letting
*any* project call themselves "OpenStack something" (which is what
living under the openstack/* namespace gives you) just because they
happen to compete with an existing openstack project sounds like a
recipe for making sure "openstack" doesn't mean anything upstream
anymore.
As a technical community, I believe we should focus on designing and
writing the best software we can, and let the software's quality,
features, ease of use, and stability speak for itself. Let the Board and
the marketing folks handle decisions around what can and can't be called
"OpenStack whatever". Provide the Board and the marketing folks with a
set of quality projects that are well-integrated, packaged consistently
with distros, and tested thoroughly for stability and scale, and leave
it at that.
Best,
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
