Re: Continued RFC process
On Mon, 09 Oct 2000 21:39:27 -0500, J. David Blackstone wrote: If enough people really feel that worried about Perl falling into the hands of a few, then something like this might be a good idea. I am quite happy with Perl as it is now, so having no say in how it should evolve, doesn't really worry me. I'll most likely stay happy with Perl. However, if Microsoft or whoever were to somehow to gain total control of Perl, couldn't somebody just go off and create a Perl-compatible p*rl, according to the GPL and/or Artistic License? Now there is something that, at least slightly, worries me. I don't think that "the Real Perl" should *ever* need to go search fo a new name. Such hostile takeovers should simply be impossible. That's why I like the fact that Laryy remains in absolute control. -- Bart.
RE: Continued RFC process
On Mon, 9 Oct 2000, David Grove wrote: On Monday, October 09, 2000 7:12 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] wrote: How about an open, crossplatform mailing list for issues, with a mechanism on perl.org for public voting on larger issues. In a volunteer organization, you can't reliably translate votes on issues into action. To be concrete, consider a perl5 example. Suppose that there was a vote to change from metaconfig to autoconf for perl5. Suppose further that the current Configure maintainer didn't know anything about autoconf and judged himself unable to complete the task in any timely manner. What would happen next? Probably nothing, unless an autoconf champion steped forward and volunteered to take over configuration issues. But in that case, what was the point of the vote? At any time, _anyone_ can step forward and champion a cause. If he or she makes a good case and implements it well[*], then it will probably be adopted. Similar concerns hold for other issues. Without a champion to implement the changes, nothing is likely to happen. With a champion, no vote is needed--the champion can just go ahead and try to do it. There are, of course, cases where things are not clear cut. Suppose, for example, that someone proposes and implements a feature (e.g. safe signals) but it has a drawback (e.g. 10% slowdown). Should that feature be included in perl? That's a tough question involving difficult tradeoffs. It's not at all obvious to me that voting is a better way to resolve such issues than the current process of allowing the pumpkin holder to decide. [*]Of course "implements it well" is a subjective criterion, but one important aspect of it ought to be a reasonable plan for the long term maintenance of the feature (usually the champion saying "I'll do it.") -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
RE: Continued RFC process
On Mon, 9 Oct 2000, Nathan Torkington wrote: Closed-for-posting mailing lists that are publically readable is the best suggestion we've had to meet these ends so far. Anyone have better suggestions? Just that it not be *too* hard to get on the closed lists (and, symmetrically, that it not be *too* hard for the list chair to bounce someone *off* the list if that person is judged to be persistently and seriously damaging to the list). I'm not suggesting anything formal here--in fact I think it's best if we make it up as we go along--just that we record our overall expectation that we're reasonable people trying to balance conflicting needs in a reasonable way. Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Continued RFC process
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Read-only access is a must for any list like this, and with more DS than just a web archive. I'm sure Ask will set things up so anyone DS that likes can subscribe to the read-only version of the list. that was in my original post about this. ezmlm can allow open subscription to all and have a fixed list of allowed posters or it can be moderated so that the list regulars can get it and sometimes others with useful input can get in. i think moderation might work unless the volume gets heavy. you can also have multiple moderators (consisting of the core of the list) which makes it easier to manage. but having public read only access is vital. you never know when an outside eye will see something that the insiders are missing (forests/tree). the lists should also be archived in the usual ways. having search functions (on the web?) would be a good addition. development lists many times will note an idea early on and forget it later. i have refound some good nuggets by looking through old email. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: Continued RFC process
David Grove wrote: Read-only and carefully censored lists are irrelevant to the goals of Perl 6's giving voice to the perl community. They lead us right back where we were before, with a core group free to sit back unchallenged on their complacency and let Perl go to rot. What does "unchallenged on their complacency" mean? In the world of OSS, those that have time and inclination design or code things they find interesting. If no one champions a cause, nothing happens. It sounds like you are saying that if the community wants Feature X and no one steps up to write the code to add Feature X to perl, then "the community" should somehow be able to force the developers that are already working on some aspect of perl to add Feature X. However, I don't agree that the developers should be able to ignore the community within a closed-off little clique. What community needs do you feel are being ignored? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Continued RFC process
"Dan" == Dan Sugalski [EMAIL PROTECTED] writes: Dan A better analogy is that Larry's the Bishop and Chief Dan Architect, while the rest of us are engineers, sectional Dan architects, artisans, craftsmen, journeymen, and apprentices, Dan working to build up a cathedral. (And yes, I do mean this Dan analogy in the way you likely think I do, amongst other ways) Ooohh, Freemasonry comes to Perl. Can I make up the handshake? :) -- Stephen "And what do we burn apart from witches?"... "More witches!"
RE: Continued RFC process
On Mon, 9 Oct 2000, Nathan Torkington wrote: Closed-for-posting mailing lists that are publically readable is the best suggestion we've had to meet these ends so far. Anyone have better suggestions? I don't know that this is _better_, but...perhaps we could have the lists that you suggest, but also have separate, publicly postable, lists where anyone could comment. If one person from the design committee would be willing to read these public lists and interact with the people there, saying "that's a good idea, we'll use it" or (probably more common) "we'd like to do that, but we can't for reasons XYZ," that would go a long way towards making the community feel invovled. Perhaps this duty could rotate, so that various design-committee voices would be heard on the outside. Dave
Re: Continued RFC process
Nathan Wiger wrote: I was going to suggest a criteria for initial membership of having authored at least a CPAN module or core patch, but I'm not sure. It seems reasonable that someone shouldn't be programming core if they haven't really done anything big in Perl before (and given it back), but I'm not sure if this is too strict. I happen to be someone who -hasn't- given anything back to Perl (yet?). Here's my 2c. (a) This will have the effect of shutting out folks that may have talent. (b) Just because someone has contributed something to CPAN doesn't mean it was of quality. It seems like this would be (sorry if I'm putting words in your mouth, David) exactly the kind of thing David would have a problem with: exclusionary based on previous perl-formance. That being said, I agree you need -some- kind of measurement of how people can/have contribute... I think that it makes sense for the -chair- of a particular section be someone with perl experience, and if they have "newbies" that can design and code, so be it. Regards.
Re: Continued RFC process
On Tue, Oct 10, 2000 at 12:34:33PM -0700, Dave Storrs wrote: is there some way we can duplicate/adapt their process so that we can simultaneously put to rest both David Grove's concerns about elitism and Dan Sugalski's concerns about lack of planning? No. -- Everything that can ever be invented has been invented - Charles H. Duell, Commisioner of U.S. Patents, 1899.
RE: Continued RFC process
On Tuesday, October 10, 2000 1:26 PM, Andy Dougherty [SMTP:[EMAIL PROTECTED]] wrote: [An offlist request for clarification, though I invite you to follow-up to the perl6-meta list if you deem appropriate] Absolutely it's appropriate. They think I'm paranoid and the only one who sees the danger. Relatively few people speak openly about it for fear of getting the same beatings I get on a regular basis. Frankly I think it's important for these guys just to realize that other people are sitting back and watching, with unexpressed interests. On Tue, 10 Oct 2000, David Grove wrote: How do we allow the core developers some peace, while giving the community FREE voice? Apart from the voting idea, do you have any other specific suggestions? The dilemma you cite is indeed real. The problem with voting is indeed just as has been described. It can be faked. Who was it... deja.com... some search engine has votings on it on a regular basis. It was basically fair until a certain point. For several months, FreeBSD and Linux topped the charts, until suddenly, in about a week, NT went from the total bottom to the total top. I think the subject was something like "secure server O/S". Similar things happened to VB in different ratings... started out sucking in the majority vote (bottom of the list by a huge margin), then suddenly it sprang up. Perhaps, then, there should be one more officer, chosen by Larry himself. This person would be responsible for collecting public opinions and representing them to the developer group, who needs to follow that guidance as long as they're technically capable. (Obviously, because of my big mouth and cynical nature, I'm not qualified, so I'm not suggesting myself.) This person must be impeachable, or at least, know when to step down when the time comes, and be trusted to know when to do so and actually do it. This person should also determine the timing of releases, or agree to the timing based on public opinion. No more of this releasing versions before they're ready or withholding modules. If we can't have a stable perl, we won't have a perl at all. Don't think that our current "information officer" is capable of accurately or faithfully filling this role, you'd be off by several hundred miles.
Re: Continued RFC process
Dan Sugalski wrote: Just that it not be *too* hard to get on the closed lists Yep, this is my only concern. It should be reasonably easy to say "I really want to help" and get on the closed lists. Perhaps the best way of making sure the lists don't bloat into "everyone has an opinion" lists is to require that *all* members contribute code to that list's purpose. If you're on the list, you _must_ program. I'd rather not limit the subscriptions to people that are coding. We need as many folks with good design skills as we can muster, and I'd rather not require them to also submit code. The two skills (coding and designing) are separate ones--good coders can (and often are) lousy designers, while good designers aren't necessarily good coders. Good design skills are also significantly scarcer than good coding skills. I think we're talking about two different things, but I do agree with you. My concern is that there needs to be *some* type of criteria for who can join a list, which is published, easily measured, and widely-understood. One part of Dave Grove's concerns I do agree with is the _potential_ (not certainty) for lists to become ad hoc, exclusionary entities. If list membership is based on intangible "this guy's cool" measurements, then there is the risk of a "good old boys" mentality. I have seen this before at my former employer (hence why I left) and it's not pretty. :-) There is the possibility of separate lists. Why not have -internals be the top-level list still? Anyone can join, anyone can comment, etc. On the spawning of the -internals-io sublist, though, only concerned developers should join. If there comes to be an impass, they can post a summary on -internals. "Ok, there's two ways we're thinking about this, whatd'ya think?" It could make things more efficient, and allow measurable list membership (anyone on -internals, coders on -internals-sublist). Anyways, I'm not trying to push my idea per se, but I do think there needs to be a widely-known criteria for list membership if it's going to be restricted. If it's ad hoc, it will likely end up exclusionary in some way - even if there are counterefforts - because people are, by nature, "clique-ish". We all like hanging out with people we know. So I think we need some type of "policy" in place - even if it's a very flexible, relaxed policy - to establish who can join lists. Otherwise we risk arbitrary decisions and exclusivity. I disagree a highly-bureaucratic, checks-and-balances approach is what we need. However, I do think a 2-3 sentence statement of purpose and membership for sublists could solve many problems. Similar to what we have with -language, but fleshed out more. -Nate
Re: Continued RFC process
On Tue, Oct 10, 2000 at 03:11:54PM -0500, David Grove wrote: Perhaps, then, there should be one more officer, chosen by Larry himself. This person would be responsible for collecting public opinions and representing them to the developer group, who needs to follow that guidance as long as they're technically capable. Well, we have two. One for the users, and one for the corporates. This person should also determine the timing of releases, or agree to the timing based on public opinion. No more of this releasing versions before they're ready or withholding modules. This is screamingly insane. The people who do the development are the people who are best placed to know when it's time to ship. Consider: "Public Opinion": Hey, we need Perl 6 stable in three weeks. Coders: But, uhm, we haven't started coding yet. No, no, no, no. He who leads the development *must* lead the release schedule. This is open source, David. You might have heard of it. Don't think that our current "information officer" is capable of accurately or faithfully filling this role, you'd be off by several hundred miles. You kind of have to justify statements like that, I'm afraid. -- buf[hdr[0]] = 0;/* unbelievably lazy ken (twit) */ - Andrew Hume
Re: Continued RFC process
On Tue, Oct 10, 2000 at 03:11:54pm -0500, David Grove wrote: They think I'm paranoid and the only one who sees the danger. Relatively few people speak openly about it for fear of getting the same beatings I get on a regular basis. Frankly I think it's important for these guys just to realize that other people are sitting back and watching, with unexpressed interests. Perhaps it's just me, but I don't see a problem yet. If Perl were somehow being "taken over", then I expect the Perl community (at the very least, one David Grove :-) to be up in arms about it. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: Continued RFC process
On Tuesday, October 10, 2000 1:33 PM, Jonathan Scott Duff [SMTP:[EMAIL PROTECTED]] wrote: David Grove wrote: Read-only and carefully censored lists are irrelevant to the goals of Perl 6's giving voice to the perl community. They lead us right back where we were before, with a core group free to sit back unchallenged on their complacency and let Perl go to rot. What does "unchallenged on their complacency" mean? In the world of OSS, those that have time and inclination design or code things they find interesting. If no one champions a cause, nothing happens. It sounds like you are saying that if the community wants Feature X and no one steps up to write the code to add Feature X to perl, then "the community" should somehow be able to force the developers that are already working on some aspect of perl to add Feature X. However, I don't agree that the developers should be able to ignore the community within a closed-off little clique. What community needs do you feel are being ignored? "Unchallenged on their complacency": knowing the issue and ignoring it because it doesn't affect them or their O/S, or in Tom's case, his personal workstation. Having a sudden shock of amazement, anger, and comprehension that the problem exists, then forgetting about it because they don't have to care. To those who don't know the old argument, which out of respect for the list and the listmaster I won't detail, I'm not talking about features so much as corporate collusion and corporate control. In the Win32 world, this has been very real, and very painful, but the P5P mostly ignored the issues because they were either not interested in Win32 affairs, or affected in other ways. The community need that I _know_ is being ignored is the ability to have a perl that's not taking a dive toward being slopped all over with the four-colored flag. Community interest must take a higher precedence in the development of Perl 6 than corporate interests, if Perl 6 is to be a "community project" at all. To those who do know the old argument and still think I'm paranoid, just see the logic in being _able_ to control the problem, since it is definitely at least a potential. To those who do know the old argument and don't think I'm paranoid, please speak up. Don't just private mail me. I _choose_ not to be paying for perl by 2005.
Re: Continued RFC process
On Tue, Oct 10, 2000 at 03:38:17PM -0500, Jonathan Scott Duff wrote: Perhaps it's just me, but I don't see a problem yet. If Perl were somehow being "taken over", then I expect the Perl community (at the very least, one David Grove :-) to be up in arms about it. And then they could fork, and Perl would stay free. Crisis over. IT'S OPEN SOURCE. David, go understand what that means. -- IBM: It may be slow, but it's hard to use.
David's paranoia again (was Re: Continued RFC process)
"David" == David Grove [EMAIL PROTECTED] writes: David The community need that I _know_ is being ignored is the David ability to have a perl that's not taking a dive toward being David slopped all over with the four-colored flag. Community interest David must take a higher precedence in the development of Perl 6 than David corporate interests, if Perl 6 is to be a "community project" David at all. Your rantings are based on unverified claims, once again. In case someone comes into the middle of this conversation, please read the past threads that reveal at every turn just how disconnected David is from reality on this point. David To those who do know the old argument and still think I'm David paranoid, just see the logic in being _able_ to control the David problem, since it is definitely at least a potential. David - some of being part of a community means that YOU won't have control. I think you keep forgetting that. There is one person to whom you will have to defer your control ultimately, and that's Larry Wall. Larry will do what he does with Perl. If you don't like it, the door is over there. Get used to that. Larry approved Sarathy's release of 5.6, including the timing and the content. Stop using that as an example of some evil corporate greed. Larry is probably one of the truest can't-be-influenced-by-corporate-greed people I know. You disrespect him when you suggest the process is being undermined. David I _choose_ not to be paying for perl by 2005. And Larry will ensure that. If you can't trust him to do that, please stop using Perl now, to cut your losses. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: Continued RFC process
At 02:11 PM 10/10/00 -0500, David Grove wrote: However what I was responding to was the shutting out of anyone who doesn't agree with the politics of the perl elite, and wants to mouth off from time to time (me). You sort of have to read between the lines on this one, Peter, because this is an old argument. Nobody's actually saying what they mean, and I think we prefer it that way. We don't prefer it that way, honestly. This dancing around the issue is damned annoying. Let's be blunt here. Your two big beefs seem to be that WinXX gets shorted in the development process, and that ActiveState is doing Evil Things. (That ActiveState has been responsible for 90% of the WinXX code in perl seems to not have made a difference, but we shan't go there right now) I don't much care about the latter problem--Larry feels he's resolved it and I'm fine with that. This is, as far as I'm concerned, his baby. As for the former Y'know what? That's probably not going to change. Perl lives and grows based entirely on contributions of source from the world. I don't have a Windows development system, I'm not at all familiar with developing on Windows, and I'm not *going* to develop on Windows. Period. You want Windows support? Great. Write the code and send it in. Don't like the install system? Go build one you do. I, for one, won't refuse code from anyone for personal reasons--if the code's solid (or there's no alternative) I'll take it no matter how much I might dislike someone. (Though it never helps to come across as a paranoid nutcase) I'll reject it on technical grounds, of course, but that's a separate matter. The problem with this is the assumption. There is _no_ assumption possible that the developers will read a free list, or care what it says. You're being too specific. There is no assumption possible that perl developers will do *anything*. Ever. This is a volunteer community. Any other assumption you might make is unfounded. There is no central authority. There is no guaranteed management control. There is no *nothing*. Perl is an open source project whose development is currently run by a group of interested parties. Don't like the way it's run? Fork the source and go for it. Dan, I don't know you. I've never had any problem with you or your leadership. That's fine. I fully expect that someone (and this is a generic someone here--I have no names in mind) will by the time this is all done. I'm not at all thrilled at the prospect, but it's one of the first things I came to terms with after volunteering. I don't believe that you'll head us into a mess, because I've no reason to believe it. You are also not technopolitically inclined in the same direction as your predecessor. I should point out two things: 1) Sarathy isn't technopolitically inclined in the way you think 2) My technopolitical leanings are likely not to your (or some other people's) tastes I have no arguments with you. However, the possibility still exists, and always will, unless some kind of check/balance system is in place. What you want isn't currently possible. Period. The only way to make it even remotely possible is to entrust perl development to some sort of entity akin to the Apache Software Foundation, and if we do that we will undoubtedly piss of yet another group of people. (And you'll likely be in that group too) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 10:48 PM 10/10/00 +0100, Simon Cozens wrote: On Tue, Oct 10, 2000 at 05:40:04PM -0400, Dan Sugalski wrote: You're being too specific. There is no assumption possible that perl developers will do *anything*. Ever. This is a volunteer community. Any other assumption you might make is unfounded. David also seems to miss the irony that the people who *can* be expected to work on Perl because they being paid to do so are probably employed by... I know, I know! Compaq, right? :) Anyway, this is generating light. Could someone start generating heat, please? Sure. This does bring up one important point, though it's getting lost in everyone jumping on Dave for being a paranoid loony. Under what circumstances, and with what procedures, do we 'officially' remove folks from their positions? I know that I, for one, will step down if either Nat or Larry asks, but what happens if for some reason I turn into a raving nutter and won't go? Or if someone just disappears and we need a new person in the position? "General consensus" is best, but that can't be guaranteed. "Consensus of the ruling council" is more attainable, but there's that whole "ruling council" thing to contend with. "What Larry says" is best, but what happens if he doesn't, or gets hit by a bus at some point? It's not a pleasant thing to deal with, and hopefully not ever needed, but it's better to deal with now when we don't have to than later when we do... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
Dan Sugalski [EMAIL PROTECTED] writes: At 09:31 AM 10/10/00 -0600, John Barnette wrote: D'you think it's a possibility to provide read-only access to the lists for interested parties? I'm certainly not competent enough to contribute to a core discussion, for example, but I have no doubt that my eventual Perl6 facility would be greatly increased by observing the dialogue. Read-only access is a must for any list like this, and with more than just a web archive. I'm sure Ask will set things up so anyone that likes can subscribe to the read-only version of the list. Ask and I have both been incredibly busy, but I believe it's even still the intention to make the traffic of the mailing lists available as newsgroups as well (with posts receiving an autoresponse explaining the nature of the mailing list and how to go about participating if the person really wants to). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Reading list
I'd like a volunteer to research and HTMLify the reading list. I collected everyone's books (and will add my list when I get back to the house). I just need someone to dig up ISBN numbers, Amazon links, and HTMLify it all into submission. Mail me direct if you want to volunteer. Thanks, Nat
Re: Continued RFC process
On Mon, 9 Oct 2000, Nathan Torkington wrote: Closed-for-posting mailing lists that are publically readable is the best suggestion we've had to meet these ends so far. Anyone have better suggestions? I don't know that this is _better_, but...perhaps we could have the lists that you suggest, but also have separate, publicly postable, lists where anyone could comment. If one person from the design committee would be willing to read these public lists and interact with the people there, saying "that's a good idea, we'll use it" or (probably more common) "we'd like to do that, but we can't for reasons XYZ," that would go a long way towards making the community feel invovled. Perhaps this duty could rotate, so that various design-committee voices would be heard on the outside. Dave I think this is what most people have had in mind all along: a read-only list for those trusted to be responsible for each portion of the project, coupled with an open list where anyone can have input. I'm talking a pair of lists for each working group/committee/whatever-you-want-to-call it. jdb
RE: Continued RFC process
At 05:59 PM 10/10/00 -0500, David Grove wrote: On Tuesday, October 10, 2000 3:27 PM, Simon Cozens [SMTP:[EMAIL PROTECTED]] wrote: Consider: "Public Opinion": Hey, we need Perl 6 stable in three weeks. Coders: But, uhm, we haven't started coding yet. Consider: Microsoft: We need Perl by April 15th Head Cheese: Ok, sure P5P: HuH??? "Public Opinion": HuH??? [Result: Perl 5.6 chaos] No, M$ didn't have much to do with it. You can yell at Larry and Camel deadlines if you like, but that's wrong too. 5.6 was released because it was mostly done, more stable than 5.005 for the bits it had in common, and because of general apathy in the developer realm for the bits that were unfinished. Like, for example, Unicode. No, offense, Dan. This isn't targeting you. I think you're starting to realize this now. At first, I think you thought I was. No, I never thought you were. Or, more specifically, I never really gave it much thought and didn't care if you were or not. You mistook courtesy, lack of time, and a desire to not appear domineering for offense. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 04:51 PM 10/10/00 -0700, Daniel Chetlin wrote: On Tue, Oct 10, 2000 at 08:23:07PM +0100, Nicholas Clark wrote: Having had cause to root around in the archives of perl6 and perl5 lists, can I suggest that we use the system that perl5-porters is archived on in preference to the system that the perl6 lists use (MHonArc, apparently). Personally I found the threaded summaries and search facility on the perl5 archive much more effective. What do other people think? Er, compared to what the perl6 lists are doing right now anything is preferable. But xray _sucks_! Given the choice between searching xray and chewing tinfoil, I might choose the tinfoil. I'm trying to get them on a regular crawl schedule at work (I work for Northern Light, one of the search engines) but that's a spotty thing at the moment. (Soon, though, I hope... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Continued RFC process
At 09:04 PM 10/10/00 -0400, Bryan C. Warnock wrote: On Mon, 9 Oct 2000, Nathan Torkington wrote: Closed-for-posting mailing lists that are publically readable is the best suggestion we've had to meet these ends so far. Anyone have better suggestions? Instead of group-writable and world-readable, how about group-writable and world-moderated? (Or just plain moderated, with the flavor o' the day being autohandled...) It's more work, which I am not a fan of, but I'm not a fan of everybody having a say, nor a select few workers having a say. I rather like it. Russ did have a point earlier, and I'm tempted to leave things open at the moment, or go the dual-subscription route and automoderate everything as OK until a problem arises. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
Dan Sugalski wrote: Works. We still have those Quantum Ninja that we're holding in reserve for Damian... :) Yeah... they're vicious, too - they kick ass in constant time. ;-) -Nate
Re: Continued RFC process
David Grove wrote: The community need that I _know_ is being ignored is the ability to have a perl that's not taking a dive toward being slopped all over with the four-colored flag. David, please, you must be more specific and less idiomatic. I don't even know what the four-colored flag is. I keep thinking I understand you, but I keep hearing you say you're not repeating everything because it's an old argument. Every time you get pressed to say more, you use this expression I don't understand. To those who don't know the old argument, which out of respect for the list and the listmaster I won't detail, I'm not talking about features so much as corporate collusion and corporate control. Could you please at least provide links to a few key messages on the p5p archives? You keep saying that others agree with what you're saying but are silent or have left. Please: where are their messages? Why can't you fork your own development process, if it means this much to you and others? Won't they join you? jdb
Re: Continued RFC process
On Tue, Oct 10, 2000 at 06:01:16PM -0400, Dan Sugalski wrote: "General consensus" is best, but that can't be guaranteed. "Consensus of the ruling council" is more attainable, but there's that whole "ruling council" thing to contend with. "What Larry says" is best, but what happens if he doesn't, or gets hit by a bus at some point? I'd be happy with "what the project manager says". We trust the project manager to be able to gauge "general consensus" and decide what's best for Perl. It gives us a "what Larry says" style polity without the sacred cow. And if the project manager goes mad (in the case of Nat, more mad :) and we have to shoot him, then Larry should do that. And if Larry gets bussed, look around at other open source projects and see what happens when the maintainer's unmaintainable - people either stick it out, or fork. I think open source has all this built in. If you go nuts, Dan, someone with authority pulls your commit access. If I think you're not nuts, then you and I go off and fork our own perl (you get to do most of the work). The better development effort wins. I repeat my suggestion from a couple of days ago that someone author a document on "how to politely fork your own development effort," something akin to the discussion on the subject from Karl Fogel's _Open Source Development With CVS_, but tailored to the Perl scene. It should be entirely possible for a person to politely start his own development on a P*rl-compatible interpreter (or even a spec) and invite developers to participate on his project without abandoning the real one. (In reality, I think we all know it's usually a little different, but it's possible in theory, at least.) Such a document, while hopefully never needed, would help remind everyone that Perl really does depend on the will of the community (and always has and always will). jdb
