Re: Continued RFC process
J. David Blackstone wrote: I'm talking a pair of lists for each working group/committee/whatever-you-want-to-call it. Hm, kinda like the clp.misc/clp.moderated duality... -- John Porter
Re: Continued RFC process
"Dan" == Dan Sugalski [EMAIL PROTECTED] writes: Dan what happens if for some reason I turn into a raving nutter Dan and won't go? What you mean "will", Kimosabi? :) -- Stephen "Farcical aquatic ceremonies are no basis for a system of government!"
RE: Continued RFC process
--- David Grove [EMAIL PROTECTED] wrote: How do we allow the core developers some peace, while giving the community FREE voice? Free being, if it's perl related, it's valid. Free by any other definition is also a farce. IMHO, the fact that this list is not in the midst of a huge flame war over your e-mails and the fact that the so-called "elite" are responding constructively to your e-mails shows me that the community is at least heading in the right direction. Glen. __ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
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/
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
Re: Continued RFC process
At 06:38 PM 10/8/00 -0400, Uri Guttman wrote: the second part is internals. not to take anything from dan, but i see a bottom up approach being very useful here. I disagree. This is too big a project to manage that way. If we do it we're setting ourselves up for an enormous amount of trouble later on. (And not that much later at that) The various pieces *must* have well-defined interfaces and behaviours, and that absolutely has to be specified before work begins on any particular piece. hammer out some working/prototype vtable code, work on the new I/O subsystems (this is a big project in its own right), work on byte code and related design issues, etc. again, these teams should be led and staffed by people with real experience in those areas. this should not be a public exercise (again read only should apply to any outsiders). Sure, as long as the behaviours of the individual pieces are known when work starts. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 06:38 PM 10/8/00 -0400, Uri Guttman wrote: the second part is internals. not to take anything from dan, but i see a bottom up approach being very useful here. DS I disagree. This is too big a project to manage that way. If we do DS it we're setting ourselves up for an enormous amount of trouble DS later on. (And not that much later at that) The various pieces DS *must* have well-defined interfaces and behaviours, and that DS absolutely has to be specified before work begins on any DS particular piece. well, i don't think we are really disagreeing. i was musing on this stuff and i have found some bottom up hacking to be useful. not the whole project, but certain well defined low level systems can be done that way. notice i also said well defined (i should have said it in my previous letter). my point is that you don't have to specify the entire system before you can spec and develop some tightly wrapped parts. or consider this work on proof of concept or prototyping. for example, you and i both want full support of native async I/O. we also agree it has to be intgrated with an event loop. we can prototype such an event loop based on several versions we have access to and integrate async file i/o into them. this would be a well defined low level subsystem below stdio. in fact it could be so general as to not even have anything about perl in it. this even goes back to simon's push for using glibc (i think that was the library he was pushing). DS Sure, as long as the behaviours of the individual pieces are known when DS work starts. well, we do know event loops and async i/o very well and could define such a subsystem right now. i am not saying do that but it is an example of how we can leverage our work force in parallel while the top down spec work is going on. again, i don't think we are disagreeing, just communicating. 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
On Mon, Oct 09, 2000 at 11:09:08AM -0500, David Grove wrote: I realize that's hard to do, and "core" developers get swamped, but without a public voice Perl 6 Public Relations - brian d foy The public relations side of development relays important events and happenings from the development side of Perl to the general public, including the press and Perl community. It's not a problem, David. -- We use Linux for all our mission-critical applications. Having the source code means that we are not held hostage by anyone's support department. (Russell Nelson, President of Crynwr Software)
Re: Continued RFC process
On Mon, Oct 09, 2000 at 01:10:57PM -0500, David Grove wrote: Perl 6 Public Relations - brian d foy Public relations? Uh, who is the Perl 6 information officer? I don't have the faintest idea. -- "You can have my Unix system when you pry it from my cold, dead fingers."
Re: Continued RFC process
"David" == David Grove [EMAIL PROTECTED] writes: David If the "public say" is limited to an RFC freeforall, then David closed off to let the elite go to work, then the whole David "public say" policy is a farce an order of magnitude worse David than the "great perl merge". Either the public has a voice, David or it doesn't. Sorry, I disagree. If I'm building a house I don't sit there and critique the way the carpenter hammers nails. I do, however, make sure the architect and I understand what the finished building will look like. The lack of difference between perl and Perl has been the greatest cause of unease, disquiet and the disenfranchisement of parts of the Perl community because it's impossible to talk about one without involving the other. Clearer seperation of language and implementation with clear specifications and a public process for the former is sufficient for this to be avoided for Perl6. It is not necessary to allow everyone the ability to comment on every phase *as it happens*. -- Stephen "Good idea, O Lord!"... "'Course it's a good idea!"
Re: Continued RFC process
This proposal has some good thoughts. Cut me some slack for not
being completely supportive of it; in my country, when they allowed
the public to ask the elite candidates for office any question they
wanted, the favorite question was "Do you wear boxers or briefs?"
How about an open, crossplatform mailing list for issues, with a mechanism
on
perl.org for public voting on larger issues. The issue would be given, 30
days
would take the polls, it would be as rig-proof as possible, and Larry would
have the power to veto (final say period). That gives a soapbox, guidelines
(Win32 and Mac are people too - elitists well we'll see),
Speaking as a Mac user, I don't know that we particularly feel left
out or anything. Then again, I'm also a UNIX user, and being both is
not the norm (at least, not until OS X catches on).
a direct public
effect on Perl, and Larry's final say over his intellectual property. Simple
majority rule on issues, 2/3 to impeach,
Do you mean impeach a person (Larry? or someone else?), or do you
mean override a veto?
simple majority per O/S to release.
That could be tricky, since the number of Perl users per OS is very
disproportionate. When they drafted the U.S. constitution, there was
a huge debate over whether to base congressional representation on
population per state or make each state equal. Both sides had a good
claim to the other being unfair; giving a smaller state (Rhode Island,
or Mac users) equal say with a larger one can seem unfair to the
larger segment, and I think in this case it would be. ("No,
seriously, guys, I think we should move the epoch to 1904.")
Takes n requests to come to a vote (keep it low until we know what we're
working with), fully automated (pre-poll or signature style). Authenticated
emails only (a la majordomo), real emails only (sorry hotmail).
This is real tricky; nearly everyone reading what I'm saying is
fully capable of writing a program to register 1000 hotmail addresses
and vote 1000 times, but this doesn't mean that all hotmail addresses
are fake (though I would presume that nearly anyone capable of
participating in this process has a real email account). Plus, the
fact that an email is from a more legitimate domain doesn't
necessarily mean that it represents a unique person; plenty of ISPs
give multiple mail accounts. Is aol.com a domain of real email
addresses? (What about wall.org? ducks for cover/)
Good? Bad?
It's simple enough to achieve the objectives, I think.
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
feel protected against such emergencies by the possibility of forking.
I realize I just broke through into a place none of us wants to go.
(Let me reiterate very carefully: *none* of us wants to go there,
least of all, me.) 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? And if not, why not? Perhaps there should even be an
officially blessed, "How to politely fork Perl development and choose
a new name if you're really that unhappy and think there's enough
people who think like you to join you" document.
The possibility of such a fork keeps me from worrying about most of
the issues you raise. However, if everyone's really that worried,
then formal mechanisms would be in order.
Let me make the following proposal: let's test your idea on itself.
Require n nominations/seconds/whatever to bring your idea to a vote (n
should be determined by you and Nat Torkington). If it does come to a
vote, conduct it in 30 days, along the lines you have said, and if it
passes with a simple majority, give it to Larry as a proposal and see
if he wants to veto it. I'll go on the record as saying I would vote
against the proposal, but wouldn't be upset if it passed.
jdb
Re: Continued RFC process
At 10:36 PM 10/9/00 -0500, J. David Blackstone wrote:
J. David Blackstone wrote:
When they drafted the U.S. constitution, there was
a huge debate over whether to base congressional representation on
population per state or make each state equal. Both sides had a good
claim to the other being unfair; giving a smaller state (Rhode Island,
or Mac users) equal say with a larger one can seem unfair to the
larger segment, and I think in this case it would be. ("No,
seriously, guys, I think we should move the epoch to 1904.")
I agree with jdb. One equivalent vote per person opens the possibility
that some company in Redmond could assign 250 of its employees to
"go vote in that Perl thing and make it ours".
Ouch. Didn't even think of that.
Or, just as bad, the vote hits slashdot and we have a half-zillion frothing
slashdotties descend on us and either vote their bigotries on us or just
screw around for fun.
Also, I'd point out a weakness in the presidential analogy for Larry.
The President of the U.S. can only veto; any legislation he ignores
passes by default. Also, the President cannot introduce legislation.
Rather, Larry is like a king; and we are his ministers, courtiers, and
noblemen. We can argue til we're blue, debate, resolve, and vote; but
in the end, it's Larry who makes the decision.
Yes, although Larry is kind of like a king after the signing of the
Magna Carta. There's no divine right, here; if Larry decides we're
going to eliminate dollar signs for scalars and optimize the core for
a Cuse Python; module, most of us will jump ship. (Though not
without tears of regret.)
I'll point out a bigger failing in the analogy. The US isn't a democracy,
none of the states are (except for the odd dabbling in, usually badly, it
with ballot initiatives), and very few municipalities are.
A better analogy is that Larry's the Bishop and Chief Architect, while the
rest of us are engineers, sectional architects, artisans, craftsmen,
journeymen, and apprentices, working to build up a cathedral. (And yes, I
do mean this analogy in the way you likely think I do, amongst other ways)
Regardless, a "design decision by majority vote" just isn't going to fly in
a mostly-volunteer effort, and it rarely does in a commercial effort.
(Whether it results in a working system is a separate matter) If you need
an example, we have Unicode staring us straight in the face. It was put on
the table both out of general need and directly to serve a large part of
the perl userbase (i.e. Windows), and look how far it got us. Heck, 5.6 was
released as tatty as it was *because* people weren't working on the things
that were unfinished.
If a proposal is put forth to handle personnel issues via some sort of
community decision, that's great. If it gets Larry's approval I'm all for
it and will follow the decisions it makes. (Even if, or especially if, the
result is I take my leave) The one thing we should *not* do, though, is
make design decisions by vote. It's worse than decisions via committee--at
least those have some hope of being technically sound.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Continued RFC process
We have just finished using RFCs for brainstorming. They served several purposes: - to provide a common reference point for discussion - to make people think through their suggestions (the hit-and-miss IMPLEMENTATION section) - to document the results of the discussion (not always effective) I've heard people asking for RFCs to continue after the brainstorming. What do we want to do that we need RFCs for? Design? Implementation? Working out the fine details of behaviour? I don't want to assume that RFCs are the right solution for this. I want to know what we want to accomplish, and then figure out what system to use to get there. We didn't begin with a good picture of what the first phase was (brainstorming, not detailed design), nor of the volume of suggestions, and some of the problems we had with RFCs came out of those mistakes. I'm trying not to repeat them. Nat
Re: Continued RFC process
"NT" == Nathan Torkington [EMAIL PROTECTED] writes: NT I've heard people asking for RFCs to continue after the brainstorming. NT What do we want to do that we need RFCs for? Design? Implementation? NT Working out the fine details of behaviour? well, this is the right time to open discussion on the next phase of perl6. i think having the rfc's open to all was overall good but i wish we had the infrastructure of the lists and stuff done before bootstrap was created. the logjam there took forever to unclog. so let that be the first lesson for our next phase. let's define it, its goals, and its structure. then unleash the hounds. some musings: i think we need two major phases in parallel here. one is to generate a decent coherent spec of the perl6 language. larry should lead that with a strong hand. no flames from the unwashed masses on his choices. larry could select teams and leaders to help him take the rfc's he likes and to refine them into a proper spec. this should not be open to the public except as read only. mythical man month is right here, we gave larry the brainstorm, now we need a clean architecture given back to us. and keeping with MMM's ideas, let's not fall into the trap of what to the rest of us programmers do? first we all have our regular lives and jobs to do so that is ok. but like he said, there are many other areas we could work on like QA tools (schwern's bag), proof of concept code, etc. the second part is internals. not to take anything from dan, but i see a bottom up approach being very useful here. hammer out some working/prototype vtable code, work on the new I/O subsystems (this is a big project in its own right), work on byte code and related design issues, etc. again, these teams should be led and staffed by people with real experience in those areas. this should not be a public exercise (again read only should apply to any outsiders). waiting for larry (and the results of my business plan contest entry). both due on friday. :) just my $.02 for now, 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
