Front page | perl.bootstrap |
Postings from July 2000
Re: Perl version of Python Enhancement Proposals [PEP]
Thread Previous
|
Thread Next
From:
Russ Allbery
Date:
July 24, 2000 03:45
Subject:
Re: Perl version of Python Enhancement Proposals [PEP]
Message ID:
ylr98jajsk.fsf@windlord.stanford.edu
Simon Cozens <simon@brecon.co.uk> writes:
> Nat told me that the people at the meeting examined various development
> models: Linux, Apache and some others, and then decided on a model
> similar to the IETFs. It's my contention that the goals of Perl and the
> goals of the IETF are very different, and the models are not comparable.
Er... woah. I thought we were just borrowing the terminology for formal
proposals. There's actually a serious proposal to model Perl development
on the IETF?
That's just an amazingly, staggeringly, horribly bad idea.
I say this as someone who's increasingly involved in the IETF, actively
contributing to two working groups at the moment and following six others
(as well as the main mailing list). IETF working groups are *notorious*
for not getting things done even remotely quickly.
In a standards organization, this is what you want. In a development
organization, this is definitely not what you want. The working group
model as practiced in the IETF puts a lot of the work and pressure on the
document editor, resulting in frequent burnout or slowness from the editor
which practically strands the working group until its resolved since the
document editor is the single point through which everything funnels. The
beaurocracy and appeals process tends to be more visible than I think
anyone really would ideally want it to be in a development organization
(again, it's appropriate for a standards organization).
IETF working groups are anything but focused; lack of focus and forward
progress is a very frequent problem. Because the group exists to talk
about some particular topic, it seems to encourage anyone and everyone who
has any thoughts on the topic at all to put them forward, even if the
group is attempting to do something specific. As a result, there are a
huge number of pie-in-the-sky proposals that the working group is
constantly dealing with.
The idea of clearly-defined milestones and due dates is probably a good
one, but I've yet to see a working group actually meet them. Milestones
are basically honored in the breach.
The IETF process is designed to make sure that the final output is usable
as a solid standard, with a clear picture of where it sits in the overall
standardization process and coverage of all the major issues implementors
are concerned with. The way in which this is accomplished in practice is
a pretty vicious survival of the fittest process; the vast majority of
I-Ds never become RFCs. It takes an immense amount of dedication and
long-term effort to actually get an I-D to the point that it's published
as an RFC.
> Documentation in this style is fast and effective. Development in this
> style is slow, boring, unproductive and generally not fun.
I wouldn't even agree with this; I'd say that documentation in this style
is slow and painstaking but *accurate* and effective once it comes out the
other end. It's not fun. The *results* are fun, but the process of
writing an RFC is not particularly enjoyable. It's a lot of hard work.
I entirely agree that this isn't the way I'd want to do development.
> Compare and contrast:
> "If you're interested in working on Perl, join the perl5-porters
> mailing list."
> I join the list, I set up a new mail filter rule, I contribute.
> "If you're interested in working on Perl, select the mailing lists
> which cover the topics you're particularly interested in, making
> sure that they haven't already done their work and have been closed
> down."
> I join a bunch of mailing lists (who was it that said email is a
> conspiracy to waste people's time?) and set up a bunch of filters, I
> work out which mailing lists are appropriate for what I want to say.
> (Argh, should posts about Windows threads go to perl6-windows,
> perl6-threads, perl6-configure or should I start
> perl6-windows-threads?!) I contribute. I get smacked down because I
> didn't write an RFC.
I'm with Simon. I never would have gotten involved in Perl development
even to the "around the edges" extent that I am if there weren't a p5p or
its equivalent.
I live and breath by technical osmosis; it's how I pick up almost
everything I'm interested in. Technical osmosis is the practice of
joining a newsgroup or mailing list for some topic, 90% of which you don't
understand, and just reading through it, letting the traffic go by, at
least reading the subjects and trying to get a superficial understanding,
day after day, for an extended period of time. Unified development lists
are wonderful for this; from years of reading p5p, I now understand Perl
in a way that I never would have if I had to sort through tons of separate
lists, only subscribe to half or less of them, and never have a unified
understanding of what's going on.
> Some people, like me, are generalists, and they'll want to read
> everything. A single list works best for these people - they've got
> everything they want to read from a single source. They also don't need
> to work out where to direct responses and comments.
This is me.
> * Maintain a central list for those who want to chip in ideas.
> * Once momentum has been achieved on an area, take the bunch of people
> away to a separate list, but still listen out for suggestions about the
> are on the main list.
[...]
> * Pumpkings regularly post status updates to the main list for two
> reasons. Firstly, so other pumpkings can make sure their plans aren't
> getting clobbered. Secondly, so that interested parties who aren't
> interested B<enough> to join a separate mailing list can provide
> feedback on the goings-on.
Thirdly, so that the generalists can see how all those cool ideas that
were being talked about earlier actually came out in the end. I like
this. This I think would work for me.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Thread Previous
|
Thread Next