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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev