Excerpts from Tim Bell's message of 2015-06-06 01:41:48 -0700: > > -----Original Message----- > > From: Clint Byrum [mailto:cl...@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. _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
