Hi, Following r30144 and r30145, can i create a top-level emacs category? I think I'm going to add some more emacs packages, i don't want to pollute the editors category. Regards, -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
On 21.10.2007, at 17:51, N_Ox wrote:
Hi,
Following r30144 and r30145, can i create a top-level emacs category? I think I'm going to add some more emacs packages, i don't want to pollute the editors category.
I think it would be nice to prefix the emacs packages with "emacs-" (like the ruby/perl/python/.. ports); if this is suitable, a separate top-level category would be unnecessary imho. -Markus --- Markus W. Weissmann http://www.mweissmann.de/
On Oct 21, 2007, at 3:29 PM, Weissmann Markus wrote:
On 21.10.2007, at 17:51, N_Ox wrote:
Hi,
Following r30144 and r30145, can i create a top-level emacs category? I think I'm going to add some more emacs packages, i don't want to pollute the editors category.
I think it would be nice to prefix the emacs packages with "emacs-" (like the ruby/perl/python/.. ports); if this is suitable, a separate top-level category would be unnecessary imho.
We name-prefix some of our ports with well-known strings (e.g. p5-* for perl modules) and still have top-level categories for them (e.g., hhmmm, perl/ for perl modules ;-). I'd favor the emacs category (and no, it aint 'cause I'm an emacs user! :-P) Regards,... -jmpp
On 22.10.2007, at 08:51, Juan Manuel Palacios wrote:
On Oct 21, 2007, at 3:29 PM, Weissmann Markus wrote:
On 21.10.2007, at 17:51, N_Ox wrote:
Hi,
Following r30144 and r30145, can i create a top-level emacs category? I think I'm going to add some more emacs packages, i don't want to pollute the editors category.
I think it would be nice to prefix the emacs packages with "emacs-" (like the ruby/perl/python/.. ports); if this is suitable, a separate top-level category would be unnecessary imho.
We name-prefix some of our ports with well-known strings (e.g. p5- * for perl modules) and still have top-level categories for them (e.g., hhmmm, perl/ for perl modules ;-). I'd favor the emacs category (and no, it aint 'cause I'm an emacs user! :-P)
...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 --- Markus W. Weissmann http://www.mweissmann.de/
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
On 22 Oct 2007, at 18:26, Juan Manuel Palacios wrote:
On Oct 22, 2007, at 3:50 AM, Weissmann Markus wrote:
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 ;-)
I would mark every port as belonging to an emacs category, but would not actually create that category. From another email I wrote:
As I have advocated earlier[1], we should begin thinking about categories not as physical bins to stick ports into (especially since many ports have more than one category listed for the port and there are 30 categories that do not really exist), but as tags in a taxonomy of ports (admittedly a very flat one, but a taxonomy nonetheless) that may or may not assist users in finding that particular port that solves their particular problem.[2]
[1] http://lists.macosforge.org/pipermail/macports-dev/2007-August/ 002560.html [2] http://lists.macosforge.org/pipermail/macports-dev/2007-October/ 003197.html Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
participants (4)
-
Juan Manuel Palacios
-
N_Ox
-
Randall Wood
-
Weissmann Markus