Open Stack

On Tue, Jan 27, 2015, at 05:46 AM, Thierry Carrez wrote:
> Doug Hellmann wrote:
> > On Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote:
> > [...]
> >> I'm open to alternative suggestions on where the list of tags, their
> >> definition and the list projects they apply to should live. If you don't
> >> like that being in the governance repository, what would have your
> >> preference ?
> > 
> > From the very beginning I have taken the position that tags are by
> > themselves not sufficiently useful for evaluating projects. If someone
> > wants to choose between Ceilometer, Monasca, or StackTach, we're
> > unlikely to come up with tags that will let them do that. They need
> > in-depth discussions of deployment options, performance characteristics,
> > and feature trade-offs.
> 
> They are still useful to give people a chance to discover that those 3
> are competing in the same space, and potentially get an idea of which
> one (if any) is deployed on more than one public cloud, better
> documented, or security-supported. I agree with you that an
> (opinionated) article comparing those 3 solutions would be a nice thing
> to have, but I'm just saying that basic, clearly-defined reference
> project metadata still has a lot of value, especially as we grow the
> number of projects.

Right. My main argument is that this isn't something for the TC to do,
not that it shouldn't be done. I'm not convinced it's that useful, but I
don't have a problem if someone else does it.

> 
> >> That said, I object to only saying "this is all information that can be
> >> found elsewhere or should live elsewhere", because that is just keeping
> >> the current situation -- where that information exists somewhere but
> >> can't be efficiently found by our downstream consumers. We need a
> >> taxonomy and clear definitions for tags, so that our users can easily
> >> find, understand and navigate such project metadata.
> > 
> > As someone new to the project, I would not think to look in the
> > governance documents for "state" information about a project. I would
> > search for things like "install guide openstack" or "component list
> > openstack" and expect to find them in the documentation. So I think
> > putting the information in those (or similar) places will actually make
> > it easier to find for someone that hasn't been involved in the
> > discussion of tags and the governance repository.
> 
> The idea here is to have the reference information in some
> Gerrit-controlled repository (currently openstack/governance, but I'm
> open to moving this elsewhere), and have that reference information
> consumed by the openstack.org website when you navigate to the
> "Software" section, to present a browseable/searchable list of projects
> with project metadata. I don't expect anyone to read the YAML file from
> the governance repository. On the other hand, the software section of
> the openstack.org website is by far the most visited page of all our web
> properties, so I expect most people to see that.

Right, I didn't think anyone would be reading the YAML file either. I
didn't realize we were planning to publish the information anywhere
other than the published version of the governance docs. That's not
really the crux of my argument, though.

> 
> > If we need a component list with descriptions, let's build that. It can
> > be managed by a team of interested parties -- perhaps some of the
> > operators or deployers, for example. I don't know if we have an existing
> > place where it would make sense to put it, or if we need a new
> > repository.
> > 
> > We've been applying DRY to the existing projects/programs
> > list and saying that because we already have a list in the governance
> > repository we shouldn't repeat that information elsewhere, but we're
> > also starting to go to a lot of lengths to define a format to hold
> > information (tags, with metadata, a taxonomy, etc.) that isn't needed
> > for project governance. That makes me think we're trying to force-fit
> > this idea into a single list.
> 
> If I understand you correctly, you'd like to have the project teams list
> (previously known as programs) in the governance repository, together
> with the list of their associated code repositories. Then you would have
> a duplicate list of code repositories, with their associated tag
> metadata, in some other repository. I understand the limits of DRY, but

No. I don't think a product list needs to have a list of repositories.
It only needs a list of products. In some cases those map 1:1, but not
in all cases. In any case, I would expect the Nova team to want their
product called "Nova" and not "openstack/nova". For teams with more than
one product, or more than one repository creating a single product, we
need the product names somewhere anyway. So let's just make a list of
product names somewhere. We can use tags or sentences or whatever to
describe them. But doing that is just writing product documentation. It
isn't project governance.

> that duplication still sounds like a maintenance nightmare (especially
> given how often the repository list is updated)... How do you make sure
> that repositories in A are in B ? Some check test at the gate ?

I trust that teams who have gone to the trouble of asking to be part of
OpenStack will want their products listed and will submit the patches to
do it.

> Alternatively we could have the project teams / code repositories
> association live in the "other repository" and just duplicate the
> project teams list, which arguably should be smaller. That means we
> would also delegate the repository scope sanity-check to the "other
> repository" maintainers, but I'm fine with that. We could have one file
> per project team and a check test that validates the project team exists
> in the governance repository. The only (small) issue with that option is
> that code repositories translate into ATCs, which translate into TC
> voters, so this is arguably a governance thing.

Right, we should keep the list of the repositories in the governance
repository. The product list doesn't need a list of the source
repositories.

> 
> >> The tagging proposal (only one-month old) has so far received a pretty
> >> good reception from operators and other downstream users, who see it as
> >> a way to explain and contribute what type of information matters to
> >> them. The Technical Committee members are not the only people who can
> >> propose tags.
> > 
> > I agree that a product matrix with some basic information will be useful
> > for deployers and operators to find project details, which can then go
> > into more depth about the issues operators and other downstream users
> > care about. I just don't think the TC needs to host or maintain that
> > matrix itself.
> > 
> > When we talk about things going into the governance repository, we
> > should apply two rules. First, we should consider whether it is
> > *appropriate* for the TC to be making decisions about the topic.
> > Subjective tags fail this test. Second, we should consider whether it is
> > *necessary* for the TC to be making the decision. Objective tags fail
> > this test.
> 
> We are a bit in the openstack-specs situation. The TC is not the only
> party involved in them (in fact, we value PTL feedback on those more
> than we value feedback from TC members), but we use the TC to
> sanity-check them, rubberstamp them or tally the votes on them. That's
> what we currently do for the code repositories lists in programs.yaml as
> well: when repositories are added to a program, we just sanity-check
> that the PTL is on board with it and that the repository still matches
> the scope of the program -- this is not a real vote and more like a
> rubberstamp. I expect our work on project lists and tags to be mostly
> the same. Each tag process would be delegated to a more appropriate or
> more necessary group, the TC would just sanity-check that the rules are
> followed before Workflow+1ing the proposed change. I think this is
> necessary, at least until Gerrit lets us express *much* more complex
> approval rules.

I'm concerned that we're building a complex process for delegating
something with TC verification that doesn't actually need to be
verified. If we're anticipating rubberstamping tags, then we should
fully delegate them. We will still manage which projects are on the
official list, which is the responsibility given to us in the bylaws,
and I trust whoever is managing the product list document to not include
anything that isn't on the official list.

Doug

> 
> -- 
> Thierry Carrez (ttx)
> 
> __________________________________________________________________________
> 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