Open Stack

On Tue, Jan 27, 2015 at 10:15 AM, Clint Byrum <clint at fewbar.com> 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.
>
> > >> 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.
>

One way we can implement this is, have the TC manage a library  that
converts a file with tag data into a document, along with a list of default
tags, and each project can import that library and include it in its docs.
This way the TC can suggest tags that make sense, but its up to individual
projects to apply them.

This is similar to what nova is doing with our hypervisor feature
capability matrix in  https://review.openstack.org/#/c/136380/

We convert a config file into
http://docs-draft.openstack.org/80/136380/7/check/gate-nova-docs/28be8b3//doc/build/html/support-matrix.html



>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150203/56b17923/attachment.html>