Open Stack

Excerpts from Tim Bell's message of 2015-06-06 01:41:48 -0700:
> > -----Original Message-----
> > From: Clint Byrum [mailto:clint at fewbar.com]
> > Sent: 05 June 2015 21:06
> > To: openstack-operators
> > Subject: Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!
> > 
> > Excerpts from Tim Bell's message of 2015-06-05 11:34:02 -0700:
> > >
> > > But if there is one package out of all of the OS options, does that make true or
> > false ? Or do we have a rule that says a 1 means that at least CentOS and Ubuntu
> > are packaged ?
> > >
> > > I remain to be convinced that a 0 or 1 can be achieved within the constraints
> > that we need something which is useful for the operators rather than
> > mathematically correct.
> > >
> > > Let’s not forget the target audience for the Ops tags.
> > >
> > 
> > Wouldn't it make sense that having coarse grained tags would help the rather
> > busy operator more than a pile of information that has to be processed and
> > inserted into an already very complex model? Nobody is saying tags can't find a
> > position on a sliding scale, like 'packaged-in-ubuntu' or 'tested-on-rhel' seems
> > like two tags that would be relevant to ubuntu or rhel users, and are entirely
> > binary.
> > 
> > Data from a real analysis is interesting, but what I really want when evaluating
> > options to spend my time on is "Is the community with me?"
> > If I can't find any tags that define what I'm trying to do, then the answer is
> > "probably not". If I grab the ubuntu packages of project X and they aren't very
> > high quality, I think the tag helps me to know that it's worth it to report bugs and
> > plow through the problems, because the community is expressing very clearly
> > "We want this to be packaged in Ubuntu."
> > 
> > Meanwhie saying something is a 74 on the packaged scale in Ubuntu is a)
> > inaccurate the moment something changes, and b) very confusing to anybody
> > who doesn't know what that scale actually means.
> > 
> 
> I worry about a large number of binary tags without a higher level structure
> 
> Packaged-in-centos7=true
> Packaged-in-ubuntu14=true
> Etc.
> 

I think I'd still much prefer this though. The set of tags that any one
individual site will be interested in will not be that large. And
looking through a list of even 100 tags for the 7 that you think should
define your site is at worst a 10 minute operation. Let's say we have a
tag for every major, LTS (supported longer than 1 year) release of RHEL,
Ubuntu, Debian, and SLES (apologies for the distros I just slighted):

packaged-ubuntu-1204
packaged-ubuntu-1404
packaged-rhel-6
packaged-rhel-7
packaged-sles-11
packaged-sles-12
packaged-debian-7
packaged-debian-8

This is 8 tags which sites will likely only ever choose two of,
and discard the rest. There would also be fringe things that might be
packaging-ish, like 'dockerized' or 'snappy-ubuntu-available'. Allowing
the community to form around their choice of software delivery without
having to fit into a particular category is quite useful for fostering
a diverse community.

> Thus, some higher level grouping which gives a structure to it. The question would then be how the UI should show the level of packaging at the level one higher up in summary.
> 

I'm not sure I understand what the question means, but I believe the
argument against structure for this is that hierarchical troves don't
scale beyond about 100 total items. Hierarchies don't really work well
when there are more than about 7 choices at each level. We're actually
better at sifting through a single large pile of seemingly-unrelated tags
than we are at selecting from several smaller piles of seemingly-related
tags.  This happens because the structure will force our choosing into the
model of the hierarchy, instead of allowing us to create our own model,
and rapidly fit the bits of the list that are relevant into it.

To test this, just think of shopping in a large grocery store. 

Would you write your shopping list only by first selecting which
aisles you are going to go into, and then once you're at the store,
looking through each aisle? I think that would be frustrating. But,
what we actually do is just think through the list of things we need,
write them down, and then go through the store with a general idea of
what should be in each aisle. The only frustrating thing now is stuff
that is on the fringes, which may or may not be in the store at all,
or doesn't have a clear aisle (like marshmallows... are they candy or
baking ingredients?  ;). Once we have the easy bits, a quick question
to a mailing list / IRC / trusted individual will confirm the existence
or non-existence of anything we couldn't find.

> For the packaging tag, I'm looking for several things
> 
> - Is it packaged on my current deployment (i.e. can I deploy it) ?

I'd think this is all any deployer would really care about regarding
packaging.

> - Is it packaged by other distros (i.e. does it have widespread support) ?

I understand why widespread interest and support would matter, but it
seems orthogonal to packaging. What if we just asked people to list the
projects they use in surveys, and if something is outside the long tail
on a graph then it gets a 'large-community' tag?

Anyway, I guess my point here is that I don't think it would be such a bad
thing to have 100 or even 200 tags, as long as there were no duplicates
and decent text search to find the ones you care about.