On Oct 22, 2007, at 3:50 AM, Weissmann Markus wrote:
...and it is not because I'm a vi-user that I may remark that the perl-category has over 500 ports while the editors-category currently has ~40; I'd say a top-level category shouldn't be introduced for every tiny new set of ports. I have no idea how many emacs-ports there would be, but if they are not exceeding ~30, I'd say put them in the anyway rather empty editors-category.
-Markus
I have to admit that I do like your point, willy-nilly categories for every couple of ports that make any sort of sense together is definitely not something we want to encourage. But it's also somewhat difficult to enforce, as there are already categories of that sort (genealogy, containing only two ports; cad, 2; iphone, 4; etc). I chose Perl as an example because of the name prefix thing, but it was a very bad example for the argument of "number of ports", I admit. I believe that some categories make sense even if they don't hold those many ports, like iphone, but others don't, like genealogy (in this case simply because it's a very small category, holding many ports would definitely make a case for it, in my opinion). So maybe our parameters for creating top-level categories should be a different one(s), rather than plain sheer number of ports in them. "How likely is a user to search in a given category?", that's the question I would ask. I (and any emacs user, I'm sure) would definitely look in dports/emacs/, so that particular category makes sense to me, even if it has only... two to begin with ;-) But, again, I want to make it clear I'm not pushing this one in particular because I'm an emacs user, but rather because I do think that we need to define a set of a parameters we can use consistently for any category, not just emacs. Regards,... -jmpp