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
