[clc-devel] suggestion for a 'proposal submission' procedure
Hey, I've talked to Jukka regarding proposals sent to clc which are forgotten after some time, and was wondering whether there are opinions regarding a policy to submit proposals which are automatically accepted after a while, if there's a certain amount of acceptance. The procedure I imagine would look like the following: 1. Submit a proposal, e.g. to cvstrac 2a discussion takes place 2b silent agreement (;-)) 4. Adjust proposal, call for vote 5a Interested maintainers vote (-1, 0, +1) there 6. After a certain time (for example 2 weeks), the proposal is either accepted or rejected I know this sounds very bureaucratic, but IMHO it's worse to make good proposals and be commited to solve existing problems and just being ignored. Please note that this is not at all meant as a criticism, just attempt to cope with reality :-) Ideas for such proposals are: - define a naming scheme for perl related ports (p5- vs- perl-); from Jukka - The guidelines about changing other maintainer's Job from Sten - "port of the week"; put up a webpage where extraordinary nice ports are published (no lengthy desciption). I e.g. discovered dnsmasq which I find _very_ handy, easy to use and working fine. Please comment :-) Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Johannes Winkelmann wrote:
Hey,
I've talked to Jukka regarding proposals sent to clc which are forgotten after some time, and was wondering whether there are opinions regarding a policy to submit proposals which are automatically accepted after a while, if there's a certain amount of acceptance. The procedure I imagine would look like the following:
1. Submit a proposal, e.g. to cvstrac 2a discussion takes place 2b silent agreement (;-)) 4. Adjust proposal, call for vote
5a Interested maintainers vote (-1, 0, +1) there 6. After a certain time (for example 2 weeks), the proposal is either accepted or rejected
I know this sounds very bureaucratic, but IMHO it's worse to make good proposals and be commited to solve existing problems and just being ignored. Please note that this is not at all meant as a criticism, just attempt to cope with reality :-)
Ideas for such proposals are: - define a naming scheme for perl related ports (p5- vs- perl-); from Jukka
the more I hit perl with ports, the more I think perl sucks. I think it's just too easy to hit dependency hell with perl ports. Case and point: spamassassin, in crux terms, I would need something like 10 perl ports. I think this should only be done if it's useful. CPAN seems like a much easier way to install perl-specific things.
- The guidelines about changing other maintainer's Job from Sten - "port of the week"; put up a webpage where extraordinary nice ports are published (no lengthy desciption). I e.g. discovered dnsmasq which I find _very_ handy, easy to use and working fine.
Sounds good. Just ban PYMP from the list, and we'll be fine! :) V
Johannes Winkelmann wrote: [...]
Ideas for such proposals are: - define a naming scheme for perl related ports (p5- vs- perl-); from Jukka
the more I hit perl with ports, the more I think perl sucks. I think it's just too easy to hit dependency hell with perl ports. Case and point: spamassassin, in crux terms, I would need something like 10 perl ports. I'm glad you mention this, since it only requires two modules to build fine and match the footprint (I did this on a pretty fresh install lately). Those modules are p5-html-parser and perl-digest-sha1; the
Hi, On Wed, Feb 16, 2005 at 00:40:27 -0500, Victor wrote: former is available in contrib (thanks Matt), and the later is in Jukka's httpup repository, but he doesn't mind maintaining it in contrib according to my knowledge. Using those two ports, installing spamassassin works fine the CRUX way (and non CPAN way, even though CPAN itself is a great thing; it's just not tracked in the package database). I guess I should have made it more clear that those modules exist as ports in http://clc.morpheus.net:6999/clc/tktview?tn=60 ;-) Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Johannes Winkelmann wrote:
Hi,
On Wed, Feb 16, 2005 at 00:40:27 -0500, Victor wrote:
Johannes Winkelmann wrote:
[...]
Ideas for such proposals are: - define a naming scheme for perl related ports (p5- vs- perl-); from Jukka
the more I hit perl with ports, the more I think perl sucks. I think it's just too easy to hit dependency hell with perl ports. Case and point: spamassassin, in crux terms, I would need something like 10 perl ports.
I'm glad you mention this, since it only requires two modules to build
Hmm, when I went to CPAN and installed spamassassin perl part, it installed way more than two modules. It is true that those two are the required ones, although if you consult the readme, you'd see that "Storable" is also required. To make spamassassin a little more useful, there are also key optional requirements: MIME::Base64 (increases speed of spamassassin significantly) Net::DNS (without it, none of the DNS tests will work) Net::SMTP (required for Spam-Cop communications) Mail::SPF::Query (Used to check DNS Sender Policy Framework) DBI *and* DBD driver/modules for your database (more listed in the INSTALL doc for spamassassin) Keep in mind that some of these have dependencies of their own. While not STRICTLY required, most of these are just too useful to ignore, and I don't recall most of these in the ports tree. I really do not think that the purpose of crux ports should be to recreate CPAN and that is what I meant about ease of dependency hell. In any case, I can update the spamassassin port to reflect the two modules you listed. However, I think the point about perl not fitting into our model well is a legitimate one. There are just too many things in CPAN and I do not think it is very useful to recreate it, especially when there are so many other ports we could be maintaining. Just my opinion.
fine and match the footprint (I did this on a pretty fresh install lately). Those modules are p5-html-parser and perl-digest-sha1; the former is available in contrib (thanks Matt), and the later is in Jukka's httpup repository, but he doesn't mind maintaining it in contrib according to my knowledge. Using those two ports, installing spamassassin works fine the CRUX way (and non CPAN way, even though CPAN itself is a great thing; it's just not tracked in the package database).
I guess I should have made it more clear that those modules exist as ports in http://clc.morpheus.net:6999/clc/tktview?tn=60 ;-)
Kind regards, Johannes
On Tue, 15 Feb 2005 15:15:43 +0100, Johannes Winkelmann <jw@tks6.net> wrote:
Hey,
I've talked to Jukka regarding proposals sent to clc which are forgotten after some time, and was wondering whether there are opinions regarding a policy to submit proposals which are automatically accepted after a while, if there's a certain amount of acceptance. The procedure I imagine would look like the following:
I don't have much to comment except that I find this approach very sensible. I suggest we embrace this procedure in order to speed up decision making. :) // Jukka
--- Jukka Heino <vector@pp.nic.fi> wrote:
I don't have much to comment except that I find this approach very sensible. I suggest we embrace this procedure in order to speed up decision making. :)
// Jukka
I agree. ===== Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
participants (4)
-
Jay Dolan -
Johannes Winkelmann -
Jukka Heino -
Victor