On 01/27/2015 01:15 PM, Clint Byrum wrote:
Excerpts from Thierry Carrez's message of 2015-01-27 02:46:03 -0800:
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.
I agree with your statement that summary reference metadata is useful. I
agree with Doug that it is inappropriate for the TC to assign it.
As do I. I think we can easily over-think the implementation of this
ostensibly simple idea.
Originally, I proposed that the tag data be managed by the
project-config-core team in much the same way that new Gerrit/Jeepyb
project applications are handled.
Best,
-jay
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.
Just like we gather docs and specs into single websites, we could also
gather project metadata. Let the projects set their tags. One thing
that might make sense for the TC to do is to elevate certain tags to
a more important status that they _will_ provide guidance on when to
use. However, the actual project to tag mapping would work quite well
as a single file in whatever repository the project team thinks would
be the best starting point for a new user.
__________________________________________________________________________
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
__________________________________________________________________________
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
