On Mon, 3 Nov 2008, James Antill wrote:
What makes the keywords smaller/bigger? The only way this works in
del.icio.us/etc. is that you have some kind of popularity metric, where
is that going to live and how is it going to be done? If "popularity" ==
number of packages in a group/tag ... then it'll be complete fail, IMO.
Smaller/bigger based on how often the tag appears in any given package.
Look at how it is done in flickr. That's the gist of it.
Also how do we display this on the cmd line?
Either:
1. we don't.
or
2. sorted most common first and have a cutoff limit on it.
Also, as Jeremy said, I haven't seen anyone say what they want the
"new" thing to be or do ... just that what we have kind of sucks (in
various ways). At a quick guess at that we have:
1. PK doesn't use it, by default.
- that's not a technical problem afaict.
2. No easy way to create custom groups for the user.
- that's unrelated to this classification, though.
3. Not wasy way for packagers to add/remove their packages from groups.
- which is the point of tying this metadata into the pkgdb interface and
having it dump out a static file. Then the packager can add keywords
through the pkgdb
4. "groupremove KDE" removes GNOME stuff, etc.
- not really related to search/browse enhancement via keyword.
5. "groupinstall FOO" && "groupremove FOO" should act like a noop.
- also not really related
6. Groups should be able to depend on groups, so we don't duplicate
data.
7. Groups depending on groups is insane.
- groupreq is doable in current infrastructure. Figuring out how to make
that behave with installs/removes is ugly, of course.
8. hierarchical groups (even though we only have 2 levels) "sucks" and
confuses people / is too advanced / etc.
- but tag browsing (which can ultimately be hierarchical doesn't seem to
boggle too many folks. See Flickr - seriously.
9. non-hierarchical groups "sucks" for 10,000 - 20,000 pkgs all in at
least one group.
- see above
11. More than 100 groups is unusable.
Which is what tags/popular tags is about.
Categorizing thousands of items is pain. Period. Figuring out a way to
make it semi-sanely browseable might not be AS excruciating.
-sv
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list