Open Stack

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.

>> 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.

> 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
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 ?

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.

>> 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.

-- 
Thierry Carrez (ttx)