Re: Perl DOC BOF
On Sun, Jul 29, 2001 at 12:48:54AM -0400, Bryan C . Warnock wrote: > Okay, fun's over. Back to work. > > There was a Perl Documentation BOF that was scheduled for 6:30 Friday; > however, it seems none of the folks who showed up actually called it, and > none of the folks who called it actually showed up. (Or showed up fairly > late - after I had already left.) > > What was it about? I'm working on some comprehensive Perl 6 reference > material for the group, but would like to take into consideration any > upcoming changes to how docs are done. > > Ziggy? You posted the note, but I don't remember for whom. Um. Wow. Casey and I didn't think anyone had seen the notice. The idea was that a few of us interested in the Perl Documentation Project (similarity to the Linux Doc Proj completely intentional) should get together and talk about a few organizational issues. A few people were interested in the PDP at the conference, but by Friday, we thought the message wasn't getting out in enough detail to have a fruitful discussion. Issues that need to be resolved include: 0. Licensing (Casey favors OPL, Bradley strongly urges FDL, with a reliance on copyright law, and I'm the simple son who knows not how to ask...) 1. Target Audience 2. Format (quick to read, quick to write docs that link together; 2 paragraph intro that becomes a daily tip) 3. Document Types (tutorial, howto, faq, what else do we need?) 4. Key areas of focus (perl5 newbies, perl6, whatever) That was it. This discussion will probably take place online sometime in the next month. Z.
Re: Perl Doesn't Suck
On Fri, Jun 29, 2001 at 05:20:40PM -0400, [EMAIL PROTECTED] wrote: > There's the trick, Solaris is Sun's Blessed Platform. As a > Linux/PowerPC user, I know how Ziggy feels. I'm almost totally > ignored by Sun and I'd imagine I'd have just as much trouble getting > it working as he did. This is the issue in a nutshell. Let's not mix business issues with technical ones. Let's not mix cluster management with simple end-user installation. Let's not mix businesses losing millions by the microsecond with the guy who just wants his little website to just *work*. [*] Personally, I don't really care what my support options are at 4am, who I can pay to rouse out of bed, or whose pager I can pay to page. I want technology that works, not technology with a glitzy sales presentation and more hype than the Beatles. I don't want technology that's unnaturally bound to customer support to make it work. I want something that works, as advertised, and works reliably enough for me to adopt it (perhaps after making a few patches). Plenty of companies find lots of work playing in Sun's (or Oracle's or Microsoft's ) view of the world. That does not define the world of computing. Not by a longshot. Let's not forget that the mainframe never died, even after 20 years predicting it's imminent demise. Remember too that the proprietary, commercially supported client/server programming languages focused on "mainstream platforms" like Win3.1+Sybase are now a footnote to history. This is especially sad with Java, which promised to be write-once run-anywhere, and continues to fail to deliver on that promise. This is especially nice with Perl, which has delivered on write-once run-anywhere without promising it, and has done so for more than a decade. Doubly so when Perl's single-implementation standard gives predictable results pretty much everywhere, while Java is subject to multiple JVMs which can be differently buggy. > But yes, module installation can be made easier. We're working on it. There are always improvements to be made, even with Perl. But where we are today, Perl doesn't suck. Z. *: What good is that multi-billion dollar business doing? Who knows. What good is that little guy doing? Who knows, but it might be the next version of the OED, a realtime snapshot of the company's P&L, or satellite data that reaches you quicker.
Re: Perl Doesn't Suck
On Fri, Jun 29, 2001 at 01:18:07PM -0500, Elaine -HFB- Ashton wrote: > Adam Turoff [[EMAIL PROTECTED]] quoth: > *> > *>Nevertheless, a degenerate case for installing Perl never requires > *>transfers or temporary disk space measured in quarter gigabytes. > > Sure it can. Allow me to clarify: a degenerate case for installing a *single* *specific* version of Perl never requires transfers or temporary disk space measured in quarter gigabytes. Mirroring all of CPAN is not a pre-requisite for installing a version of Perl, multiple versions of Perl, etc. > *>Worst-case-to-worst-case, Perl doesn't suck, and it's doing much > *>better than Java. I wonder which is easier to support post-install. > > Perl can suck and often does for the newcomer who, when faced with trying > to wade through all the XML modules on CPAN trying to figure out which one > is which for what purpose, can be quite frustrated with getting things to > work as advertised. That's not the issue here. Chris and I are talking about the case where a user finds a piece of software requiring (Perl|Java) and need to install the language distribution as well as the software requiring that distribution (or, a simpler case of installing a specific version of a language distribution). Wading through CPAN is not an issue here. > Everything can suck given enough scrutiny. Surely. And if you want to believe that Perl sucks, please do. While installing Java this week, I stumbled across the "installation experience" and "supported platforms" aspects of a language and found that Perl is doing remarkably well, even if no one takes the time to say so. I chronicled my experiences in detail to show how bad it can be, and to highlight how remarkably well-engineered and supported Perl is by comparison. Z.
Re: Perl Doesn't Suck
On Fri, Jun 29, 2001 at 12:02:28PM -0400, Christopher Masto wrote: > Having gone through much the same pain a couple of weeks ago (although > I just broke down and installed the linux-jdk-1.3.1 port after Sun's > web site told me to come back later), I eagerly await a pure-Perl > replacement for FOP (http://xml.apache.org/fop/index.html)). For the brief period of time when I was working for a commercial software vendor, GOOBE was a priority (good out-of-the-box experience). FreeBSD + Java may be an extreme case of poor GOOBE for Java, but it's not just Java that's the issue here; it's the GOOBE for Java products. I can't remember when I had such a truly bad experience with Perl or products based on Perl (primarily through CPAN). The worst I've seen is configure asking for input from the console (do you want feature X?), failing for cause (you must install libexpat.so on your system; find it here), or forcing Perl to be upgraded (mismatched module versions). That's not to say that there aren't issues with buggy modules, missing compilers, etc. Nevertheless, a degenerate case for installing Perl never requires transfers or temporary disk space measured in quarter gigabytes. Worst-case-to-worst-case, Perl doesn't suck, and it's doing much better than Java. I wonder which is easier to support post-install. Z.
Perl Doesn't Suck
What follows is a long, detailed summary of an attempt to install JDK 1.2.2 on FreeBSD today. FreeBSD/JDK 1.2.2 is an unsupported configuration for Sun, although patches exist to get the JDK to work under FreeBSD. Skip to the last two paragraphs if you want to see how this installation compares to a standard Perl installation, and what this means for Perl. Please read the rest if you want to see what a 'simple' installation took for this version of Java. (Note: JDK 1.1.8 is supported, but JDK 1.2.2 isn't, and some software requires JDK 1.2.2 (Java2)). Comments welcome. Z. --- I recently had occasion to upgrade Java on my FreeBSD installation at home. I have both the Java Runtime Environment (JRE), v1.1.8 and Kaffe 1.0.6. I deal with XSLT a lot, so keeping these around is a necessity when dealing with XSLT engines, such as Michael Kay's Saxon and James Clark's xt. The JRE apparently comes directly from Sun and contains only the virtual machine required to execute Java programs. It lacks things like documentation and javac, the Java compiler (written in Java). JRE 1.1.8 implements the Java 1.1 specification, which appears to be useful, but out of date compared to the current Java 2 specification (JDK 1.2 and above), and the imminent Java 1.3 release. (I'm going on memory here; there's so much *stuff* on java.sun.com, it's quite difficult to easily determine whether Java 1.3 is shipping, in a late beta cycle or in an early PR cycle.) As the name would imply, the JRE is just that - a runtime environment. Unfortunately, it's not the kind of "run anywhere" environment you would expect from Java. To be fair, it's only Java 1.1, and that's OK. But it's insufficient for running applets in my favorite web browser du jour, Konqueror. So I installed an Open Source reimplementation of Java 1.1, Kaffe. Now, whenever I visit java.sun.com, Konqueror loads and runs the applets through Kaffe, and I get a familiar grey box which says "Loading Applet". And a core file from Kaffe whenever it's invoked. But Kaffe also runs Java programs without a hitch, just like the JRE. (Note: Kaffe may not be fully compliant, but it runs what it's supposed to run, and it doesn't crash, except within Konqueror and running applets.) At this point, you probably think this is another rant about Java being a bad language, unsuitable for software development, or an example of immature software being thrust upon the uncaring public. It's not. Java is a fine environment, and until today, I never had to think about it, even though I use programs written in Java every day. The fact that Saxon is implemented in Java is an unimportant fact that sits buried in a Makefile or two. It's as unimportant a detail as cvsup being implemented in Modula-3. In a sense, that's the hallmark of good software -- it should do a job, do it well, and stay out of the way. The JRE and Kaffe do that with Java 1.1 software. If only Java 2 would be so unobtrusive. I installed Java 1.2.2 today because I want to start using other XML technologies, like SVG. The Apache XML project is working on a project called Batik that will do pretty much anything with images in the SVG format. All I really want to do is generate SVG files using XSLT, and translate vectorized SVG files into rasterized PNG images. Batik promises to do that, and much, much more. As I said before, I'm running FreeBSD. This should be a simple pair of commands: 'cd /usr/ports/java/jdk12-beta; make install'. The native JDK 1.2 port appeared within the last few weeks or so; previously, to run JDK 1.2 applications, the Linux JDK needed to be run, and that was one too many levels of emulation to consider. So I start with the obvious. And it doesn't work. To install the jdk12-beta port, the JDK sources and patches need to be downloaded manually; this is because of some licensing issues with Sun, where the sources are available only to registered developers. Annoyed, I register and get the sources, and then the patches. Due to poor web design on Sun's site, it took a while to actually find the links for downloading the sources -- it's almost like Sun doesn't want you to find them. Getting the patches was easier, although it also involved a clickwrap check, since the patches are only available to developers who have registered with Sun's developer program. (Who *else* would be interested in patches to the JDK?) Having downloaded, about 18MB of software, I start the build process. Yes, the JDK sources are about 18MB. Compressed. Now time to let the port build itself. The wonderful thing about ports is that build and runtime dependencies will be checked, and installed as required. After downloading, extracting and patching the 18MB JDK 1.2.2 sources, the very next thing that happens is that the full JDK 1.1.8 is installed as a build dependency (Sun's JDK, as binaries, including 'javac'). Then the Linux version of the JDK
[ANNOUNCE] Apprenticeship Hour at YAPC::NA
As some of you may have noticed from the YAPC schedule[1], I'll be hosting the "Perl Apprenticeship Hour" next week. I'm STILL looking for brief descriptions of projects that are looking for some help, including: * documentation* tools * tutorials* bugfixes * modules * enhancements to existing code * websites * collaborative efforts * test code* program suites If you plan to attend YAPC::America next week, and have: - an idea for a project, but need extra tuits - an idea for a project that would be a good way to mentor a beginner - an idea for a project, don't have time to do it, and don't have a lot of time to explain it then please send a brief description ASAP to <[EMAIL PROTECTED]>. The apprenticeship hour will be run much like mjd's Lightning Talks, where presenters will have ~5 minutes next Wednesday to discuss an idea for a project. Thanks, Z. [1] http://www.yapc.org/America/talks.shtml#schedule
Re: Perl, the new generation
On Fri, May 18, 2001 at 08:08:40PM +0100, Simon Cozens wrote: > On Fri, May 18, 2001 at 12:55:55PM -0400, Stephen P. Potter wrote: > > Atoms- Unicode. If everything is Unicode, you're going to have to grok > > Unicode (at least tangentally) to be able to use perl. > > Bah. Rubbish, no more than you need to grok Unicode to use Perl 5.6. > Do you know what data of yours 5.6 is storing in Unicode? No. > Do you care? No. Do you need to? No. One of the big selling points about Java is that it's always use Unicode natively from day 1, yet I've never seen a "Unicode Primer for programmers starting out with Java" book/site/article/paper/certification. Unicode is just *there*. Much like oxygen and nitrogen. The tangential deviation necessary to grok unicode to use Perl is perhaps .01 degrees away from the previous learning curve. Using Perl to grok Unicode is a little different. :-) Z.
Re: Perl, the new generation
On Wed, May 16, 2001 at 01:32:26PM -0600, Nathan Torkington wrote: > In that case, how exactly has it forgotten its roots? I mean, in what > way is it not as useful as it was before? [Please forgive the following marketspeak] The issue isn't that Perl is less useful now. It's that it's shifted on the utility curve. Five years ago, N units of effort would produce a value of 1.5 N to 10 N. (The variance describes the cost of that effort; learning a programmign language is more costly to a graphic designer than a CS grad student). Today, that same effort is producing less value, perhaps less than 1:1 for some. This isn't an isolated ecosystem, and some languages offer 1:2 or .5:3 [hypothetical] cost:benefit ratios (e.g. Python, Ruby), while others offer 1:.5 (e.g. C++, proprietary languages). Now, these aren't solid numbers, nor is this a valid economic/marketing argument. It's just trying to describe how the perceived value of learning Perl (or learning more Perl) is declining over time because of the perceived complexity. In other words, why should someone learn *more* idiosyncracies and complexities when they can spend the same amount of time learning Python? Z.
Re: Perl, the new generation
On Wed, May 16, 2001 at 12:49:00PM -0600, Nathan Torkington wrote:
> If you work in a team, then the bar is raised to the union (not the
> intersection) of everyone's knowledge. But team programming is not
> for small trivial tasks, and if you're solving large complex tasks
> then it's unsurprising that you'd need some of the more advanced
> features of Perl.
In some cases, it's the union. In other cases, it's the intersection.
I've worked on projects where the N+1st member of a team brings new
techniques that really help everyone's code.
I've also worked on projects where the N+1st member of a team starts
writing idiosyncratic code that no one else can read or debug
(especially when using inheritance and closures).
It's also amazing how long some people can go without seeing a
statement modifier or non-default delimiters like s{}{};. In the
micro view, that's OK. In the macro view, it leads to Perl Mongers
meetings that feel more like AA:
"I've been using Perl for three years, and I'm still a beginner"
"How does 'open($f, $filename) or die;' work again?"
"Prototypes? You mean like C?"
"I still need to sit down and learn regexes. They're still confusing."
Z.
Re: Perl, the new generation
On Wed, May 16, 2001 at 08:57:42AM -0700, Peter Scott wrote: > It doesn't look to me like the amount of Perl one needs to know to achieve > a given level of productivity is increasing in volume or complexity at > all. What it looks like to me is that there are additional features being > added which enable one to achieve greater levels of productivity and > performance if one wants to learn them. Who *wants* to be unproductive? Z.
Re: Perl, the new generation
On Tue, May 15, 2001 at 03:41:15PM -0600, Nathan Torkington wrote: > Stephen P. Potter writes: > > It seems to me that recently (the last two years or so) and > > especially with 6, perl is no longer the SAs friend. It is no > > longer a fun litle language that can be easily used to hack out > > solutions to problems. It is now (becoming) a full featured > > language, quite at the expense of its heritage. > > And yet there are a zillion programs from perl4 and earlier that still > work in perl5. In what way can you not use Perl to solve sysadmin > problems or hack out fun solutions to problems? I do those two things > all the time. I don't think backwards compatibility is the point here. I picked up Camel 1 recently, and it was quite amazing how different Perl4 *felt*. It's like Perl was being pitched as a good language for writing standalone programs or utilities of standalone programs (the type a sysadmin would use). It didn't feel like it was being offered as the kind of language to write things like Class::Contract, Inline::C, AxKit, SOAP::Lite or the all-singing-all-dancing CGI.pm. Where are we now? Perl5 is a bigger language and Perl6 is proposed to be bigger still. There are people who complain about Perl5 because they "can't keep it all in their heads", unlike C, sh and Python (and to some extent, Perl4). > > When we moved from 4 to 5, so people thought we should continue > > developing 4 without all the "useless" new stuff, like OO and > > threads and etc. I wonder more and more if they weren't right. I > > wonder if as 6 develops if we shouldn't split off the old 4 syntax > > and have two languages. > > If you want to do it, do it. I vomit at the thought of a language > without data structures or modules, though, and I wouldn't be > surprised if others did too. It's not so much that Perl shouldn't have data structures or modules. I think what Stephen is saying (and he's not the only one) is that the bare minimum amount of Perl you *must* know to be productive is increasing. Either that, or we're giving the impression that it's increasing. Many people don't want to get bogged down in how the details of Unicode, upperclass level CS topics or Perl's unique syntactical peculiarities to parse a damn log file (or find and use a CPAN module that does it). Z.
Re: You will not have to rewrite your Perl 5 programs!
On Thu, May 10, 2001 at 02:58:50PM -0700, Nathan Wiger wrote: > * Dan Sugalski <[EMAIL PROTECTED]> [05/10/2001 14:18]: > > > > > >Perl 6 *will* provide a backwards compatible Perl 5 parser. The > > >details are not nailed down, but this definately will happen. > > > > Damn straight. One way or another, perl 6 will eat perl 5 code close to > > painlessly. (Typeglobs, perhaps, aside) > > Cool. Dan, is this a fundamental change from the philosophy that you > expoused earlier? Last time I brought this up it seemed you were > against having perl6 eat perl5 code. I'm thinking specifically of: > > http://www.mail-archive.com/perl6-language@perl.org/msg06258.html > > I'm NOT trying to put you on the spot :-), just wondering if the > philosophy has changed... Yes, it has, in Apocolypse 1: Perl 6 must assume it is being fed Perl 5 code until it knows otherwise. http://www.perl.com/pub/2001/04/02/wall.html Just as a point of clarification, Perl6 started when Larry realized that we can start from scratch, redefining the language and using B::* to port Perl5 programs forward to Perl6. The current thinking is that much of the Perl parser will be written in Perl. At that point, if the Perl6 language definition doesn't see any Perl6 constructs, it can switch itself out and plug in a piece of Perl code that parses the Perl5 language instead. So the last ditch effort to run old code through p52p6 is truly a last ditch effort. Z.
Re: Perl, the new generation
On Thu, May 10, 2001 at 05:23:01PM +0100, Simon Cozens wrote:
> On Thu, May 10, 2001 at 09:20:13AM -0700, Peter Scott wrote:
> > So, I wonder aloud, do we want to signify that degree of change with a more
> > dramatic change in the name? Still Perl, but maybe Perl 7, Perl 10, Perl
> > 2001, Perl NG, Perl* - heck, I don't know, I'm just trying to get the
> > creative juices flowing.
>
> As a data point, Python are currently in the middle of a Perl 6 style
> redesign, and are calling the result Python 3000. Maybe if we called it
> Perl 3000, we might be able to get a beta out by then.
My understanding of Python 3000 (from some of the Python folks at ActiveState)
is that Py3K isn't a "next major version", but rather a gedanken experiment
of some far off future version of Python where everything magically fits.
It's like the Rocky Mountains, as seen from Iowa. :-)
The Python folk are working to improve their language, primarily with
the current source base; 2.x isn't a rewrite, but 1.5.x with some nifty
new linguistic features added in (I think that's when list comprehensions
entered into the language (er, map {} LIST)). And, then there are the
multiple parallel reimplementations of the Python 2.x language: jython
and stackless python (among others, surely).
Perl6, OTOH, has always been conceived as an effort to first find out
everything that's possibly broken with Perl5, and take one last shot
to fix it as our next big development project. Like the Rocky Mountains
as seen from Colorado. :-)
Z.
Re: Not revisiting the RFC process (was: RFC 362...)
On Thu, Feb 22, 2001 at 01:41:22PM -0800, Edward Peschko wrote: > On Thu, Feb 22, 2001 at 04:04:31PM -0500, Adam Turoff wrote: > > 1) The RFC was a free-for-all brainstorming process. Intentionally. > > right, and your point is that brainstorming should cease(?) Yes. Everyone (else) seems to agree that Larry has a tough enough job to do right now without increasing his workload by extending the RFC process. > yeah, and there are not nearly enough of these 'features', 'comments', 'what > have you' available. There is a *lot more to say* in this type of forum. That's one opinion. > > 3) The RFC process was designed to be a limited call for ideas for Larry > > to consider in a language design. The deadline was integral to the > > process, and decided before RFC collection began. > > right.. and like I said, I don't understand the 'limited' part. That doesn't sound like a compelling case to unlimit the process. Perl6 isn't a never-ending RFC gathering exercise. It's a community rewrite of Perl. > Exactly... and your point is that 'the number of things that perl6 which Perl > could or should become' is now fixed in stone? That statement significantly misrepresents and underestimates the nature of Perl. Perl4 and Perl5 were not fixed in stone, and they both went into interesting unforseen directions (including tkperl/oraperl and Inline/Perligata, respectively). Perl6 will not be set in stone, either, but the baseline needs to be complete enough to accomodate current needs and desires, and flexible enough to invent the rest. Z.
Re: Not revisiting the RFC process (was: RFC 362...)
On Thu, Feb 22, 2001 at 12:00:45PM -0800, Edward Peschko wrote: > As I stated in the original post, there is no reason *not* to keep the > process open. In an attempt to keep my previous message concise, I seem to have neglected a few key points: 1) The RFC was a free-for-all brainstorming process. Intentionally. 2) RFCs were not intended to be the basis for designing the language or describing/creating the implementation. They were intended to collect comments on the aspects of Perl5 that should/could be fixed in Perl6, or cool new features that cannot be reasonably added into Perl5 but could be integrated into Perl6. 3) The RFC process was designed to be a limited call for ideas for Larry to consider in a language design. The deadline was integral to the process, and decided before RFC collection began. > The RFC's would be a very good tool to sift discussions, let > ideas flow, and not to revisit discussions in the future. 4) The RFCs have demonstrated that they are a very poor tool for starting and continuing a productive, forward moving discussion. Many of these issues are addressed in PDD 0 and Dan's thoughts on the PDD process. > [...] Dan Sugalski replied that the RFC > process *was* going to be ongoing, so I was willing to have it hit the next > 'cutoff'. The formal (more-formal-than-p5p) document gathering process will be ongoing. That is one reason (of many) why the PDD series is emphatically not a series of RFCs. We made mistakes with the RFC process and don't want to repeat them. > Hell, I was going to make an RFC searcher, commentor, and so forth that could > be re-used for PPD. I have no interest in making such an engine if PPD only > exists, because I think that PPD by itself is clearly insufficient to handle > the needs of the perl community. There's nothing stopping you, but the RFC archive is closed and will likely not be reopened (save for some minor details in the queue). It's primary value is in cataloging a series of ideas of what Perl could or should become. > So I ask you - *why* make an artificial deadline? What's the point? The deadline was not artificial. It was by design. > Do you > really think that RFC's as they stand equal all the large issues that are going > to be faced with perl6? No, and there's nothing wrong with that. > I'm sorry, but this pisses me off. You've got to realize that for a lot of us, > our time is intermittent and our commitment can only be sporadic. All the more reason to focus on building the future, not polishing the past. > I, for one, > was busy in transitioning to another state when the whole perl6 design thing > happened last year. So hell - I plan on giving my contribution now. What's > better - that, or twiddling our thumbs? If you want to contribute, patch bleadperl, or make a contribution on what we're doing today. Z.
Not revisiting the RFC process (was: RFC 362...)
On Mon, Feb 19, 2001 at 07:20:33PM -0800, Edward Peschko wrote: > > As much as I'd like to respond to some of these points, I'll refrain from it > now, I'll let my RFCs speak for themselves. Ed, The RFC process that we started this summer is formally and intentionally closed. Your post, regardless of it's formatting, naming or intent, will not be accepted into the RFC archive. > =head1 TITLE > > The RFC project should be ongoing and more adaptive. First, Dan Sugalski has accurately summarized the nature of the process, describing the current state of 'pause' we find ourselves in. http:[EMAIL PROTECTED]/msg00707.html Second, recent discussion of Bryan Warnock's PDD 0 addresses the issue of adaptability of the Perl 6 process. The thread (from this week) starts here: http:[EMAIL PROTECTED]/msg00712.html > =head1 ABSTRACT > > The RFC process should not have had an artificial deadline; it should be an > adaptive process that should last the entire development cycle of perl6 and > perhaps after. Again, the RFC process is closed. If you have ideas on how we can improve the quality of documents yet-to-be-written (e.g. the PDD series) or the process of obtaining such documents, then please focus on work that remains to be done, not artifacts that don't need to be polished. Z.
Re: State of PDD 0
On Wed, Feb 21, 2001 at 07:44:51PM +, David Mitchell wrote: > > Also, if we go down the 'have a competition to see who can write the best > PDD on subject X' path, can we replace the 'TBD' in unnumbered PDDs > with a short string chosen by the author? This allows us to (hopefully) > unqiuely refer to a document during disussions, but when a final winner > is chosen and given a number, the offical library can still pretend the > losers never existed, unless people look in the 'losers' section. > EG > PDD-dapm-GC > > rather than > > PDD-TDB > > for my attempt at garbage collection or whatever. There are advantages with using simple enumeration for RFCs/PDDs. (I'll beat that dead horse only upon request.) The disadvantage of switching to a more descriptive naming scheme is that any identification attached to a PDD upon receipt must be final; a PDD cannot be renumbered/renamed once it has been accepted into the archives. To do so would make it more difficult to search the archives for discussion about an idea -- searching on PDD-std-vtbl won't find the threads that lead to that standard, when it was called PDD-sugalski-vtbl. Perhaps a more descriptive prefix/suffix notation on PDDs would improve upon the anonymous nature of RFCs/PDDs, so long as a core name is assigned to a document never changes. Z.
Re: State of PDD 0
On Tue, Feb 20, 2001 at 08:58:03PM -0500, Bryan C . Warnock wrote: > On Tuesday 20 February 2001 20:32, Adam Turoff wrote: > > For example, I doubt that we want or need three competing PDDs on > > Async I/O developing in the Standard track, but multiple PDDs on > > the same topic would be welcome if they were Experimental (or even > > Informational). > > The idea, unlike the RFC process, wasn't that PDDs were to lead the > discussion. A PDD proposal was more or less a checkpoint in the > development process. PDDs, like the RFCs that preceded them, will need to serve multiple purposes. One of them will be to catalog (and *name*) ideas that keep coming up, including the bad ideas (like the |||= operator) that we're tired of discussing. I don't think anyone expects each of N PDDs to get us 1/Nth closer to Perl6. Some PDDs, especially Informational and possibly Experimental, might need to precede knowledgeable discussion. If so, then Standards-track need to have the requirement that they summarize some amount of discussion on the list(s), and that requirement is enforcable (i.e., no PDDs out of left field). That's a good idea, but I'm not entirely convinced that it's the only one, the fairest one or the most practical one. Z.
Re: State of PDD 0
On Tue, Feb 20, 2001 at 05:42:01PM -0500, Dan Sugalski wrote: > At 02:38 PM 2/20/2001 -0800, Ask Bjoern Hansen wrote: > >How should the submission process work? As for the RFC's? > > Sounds good to me. Any additional constraints on acceptance criteria? PDD 0 describes an acceptable baseline on rejection (return incomplete submissions), but I daresay that we want something more strict. For example, I doubt that we want or need three competing PDDs on Async I/O developing in the Standard track, but multiple PDDs on the same topic would be welcome if they were Experimental (or even Informational). Would any other constraints help to promote discussion moving forward? The goal isn't to be burdensome on people actually volunteering their time, but to cut down on the crosstalk that doesn't lead to Real Work(tm). Z.
Re: "Art Of Unix Programming" on Perl
On Sun, Feb 11, 2001 at 05:03:12PM +, Simon Cozens wrote: > There's obvious FUD out there and we don't seem to be giving the impression of > getting much done, or doing anything to counter it. Let's be fair. We're not getting much done, and that's a *GOOD* thing. Language design is a very tough nut to crack, and we decided (as a group) that we don't want a language designed by committee, we want a languaged designed by Larry. The best we can do (frustrating as it may be) is to let him think deeply. Remember, one of the basic tenets of Perl6 is that Perl5 isn't going away, nor is it fundementally broken. > Part of the problem is > that we don't currently have anything that we can point to and call progress. > That's a problem in itself, because if people don't see progress they lose > interest and go away. Perhaps. If they go away to hack Perl5, is that a problem? If they go away to hack Python or Ruby, were they really _that_ interested in Perl6 in the first place? And is it really a problem if the lack of interest magically disappears when Larry returns? Rushing the process because of intermittent PR problems isn't going to make Perl6 any better at achieving it's goal - solving tomorrow's problems better than Perl5. Z.
Re: Guidelines for internals proposals and documentation
On Wed, Nov 15, 2000 at 04:20:58PM -0500, Dan Sugalski wrote: > I want perl 6's internal API to have the same sort of artistic integrity > that the language has. That's not, unfortunately, possible with everyone > having equal say. I'd like it to be otherwise, but that's just not possible > with people involved. There are many people who have good taste and experience where the Perl API is concerned. Forcing those people to come to a majority vote on every PDD isn't going to fly. The answer isn't to reduce that set of people to one person; Larry doesn't scale exponentially. > The point is definitely *not* to do any sort of consolidation of power. > Anyone reasonably sane, capable, and interested is welcome to chair any of > the internals design lists and/or be responsible for shepherding a PDD to > solidity. That's fine with me. (In fact I'd be thrilled if the design was > handled by a host of folks that weren't me) There are only a small number of people who can bless/unbless a PDD into a standard or forcibly withdraw it from consideration. It's good that there's a small number (>1) is involved, but it's bad that each of those people can singlehandedly bless/unbless something. >From p5p, we saw that if 2 or 3 people objected to a proposal/idea/patch, it was probably flawed in some way. OTOH, if 3 or 4 of those same people saw merit in a proposal/idea/patch, then it was probably worthy of consideration[*]. This is one of the ways where p5p worked well (and where the RFC process failed). We should formalize this for the Perl6 API process. The first order of business should be to determine the process by which PDDs become accepted/rejected/mentored/etc. Next, we find the people with good taste and spare tuits to accept/reject/mentor proposals through the process. Z. *: This is the audience-participation variant of "throw it at the pumpking and see if he accepts it."
Re: Guidelines for internals proposals and documentation
On Wed, Nov 15, 2000 at 04:42:58PM +, Nicholas Clark wrote: > On Wed, Nov 15, 2000 at 11:35:56AM -0500, Adam Turoff wrote: > > All PDDs (like RFCs) need to start with 'Status: Developing' by default. > > Since statuses like 'Standard', 'Rejected', etc. have Real Meaning (tm), > > there should be some review in place (by a WGC, principal, etc.). Statuses > > like 'Withdrawn' and 'Superceded' should be accepted from PDD authors/teams. > > They don't need to start with "Developing" if they start with status > "Experimental" or "Proposed" The real issue is that there needs to be at least one default status that the author can assign. With RFCs, Developing referred to the RFC, and with PDDs, they refer to the underlying design/interface/implementation. I think I misread Dan's re-interpretation of 'Developing'. > > This is a community process. I'm uncomfortable leaving such decisions > > to such a small number of people. How about nominating/electing a > > If PDDs start as "Proposed" without needing any approval does this remove > the problem of a small group having a stranglehold? No, because Dan has proposed a 'core team' of sorts, where any one of the (at least) three team members cast a final vote (towards 'standard' or 'rejected'). Keep in mind that this isn't "Dan's Perl API" (or Nat's, or Larry's), but "Our Perl API". I'd be more comfortable if at least two people (from a group of >4) were involved in making any decision that carries weight, or if there were a process of rotating the WGC as necessary to avoid Pumpking Burnout (tm). Z.
Re: Guidelines for internals proposals and documentation
On Tue, Nov 14, 2000 at 05:59:40PM -0500, Dan Sugalski wrote: > 6) Only a WG chair, pumpking, or one of the principals (i.e. Me, Nat, or > Larry, or our replacements) can mark a PDD as developing, standard, or > superceded. This doesn't sound right. All PDDs (like RFCs) need to start with 'Status: Developing' by default. Since statuses like 'Standard', 'Rejected', etc. have Real Meaning (tm), there should be some review in place (by a WGC, principal, etc.). Statuses like 'Withdrawn' and 'Superceded' should be accepted from PDD authors/teams. The RFC process accidentally required single-authorship for all RFCs. We should allow RFCs to be maintained by a group of collaborating authors (without forcing them to start a mailing list first). Any of these authors should be able to make updates and update the status as appropriate (e.g. Developing, Withdrawn, Superceded). This is a community process. I'm uncomfortable leaving such decisions to such a small number of people. How about nominating/electing a core team that will be responsible for the API design, whereby a vote of 3/10 is needed to reject a PDD and a vote of 5/10 is needed to accept a PDD? (The numbers 3, 5 and 10 are arbitrary, and used to demonstrate that this doesn't need to degenerate into review by committee.) Z.
Re: The new api groups
On Tue, Nov 14, 2000 at 12:58:25PM -0500, Dan Sugalski wrote: > (Though I don't think we really need more than a few weeks to get a good > set of working RFCs for this, though of course they'll get amended and > expanded as work proceeds) I'd like to see a revised set of RFC guidelines specifically for the api groups. The Brainstorming process that we encouraged in August/September isn't going to be as useful for talking about possible directions for internals. Internals RFCs should be about getting the plan for the internals mapped out, not revisiting the same tired discussions on vtbls, threaded bytecode or femtosecond opcode dispatchers. Specifically, I'd like to see stricter acceptance/rejection criteria for RFCs inclusion in the library. Z.
Re: Transcription of Larry's talk
On Wed, Oct 18, 2000 at 10:58:45AM -0700, Larry Wall wrote: > Yes, but if we go down that route, we're gonna end up with all the > verbs at the end. Instead of "print @foo", we get something like: > > @foo wa kaite kudasai; So, mitsu no @foo wa kaite kudasai; # print $foo[3]; That brings up two questions: - what's the ordinal for 'zeroth' - are lists 'long-flat-objects' or 'tall-cylindrical-objects' or 'short-fat-cylindrical-objects'? Inquiring gaijin want to know! :-) Z.
Re: how the FreeBSD project gets its "core members"
On Mon, Oct 16, 2000 at 10:37:27PM -0700, Nathan Wiger wrote: > - The core team appeared to be doing too much, meddling in affairs > which didn't concern them. http://www.freebsd.org/FAQ/misc.html#AEN4823 Q: Why should I care what color the bikeshed is? A: The really, really short answer is that you shouldn't. [ annecdote about everyone arguing about the bikeshed, but no one arguing about the nuclear power plant next door. The bikeshed is easily understood, meaningless, and the source of endless arguing. The power plant is huge, complicated and confusing, so no one comments about it. ] :-) Z.
Re: I18N of Perl 6 (was: how the FreeBSD project gets its "core members")
On Mon, Oct 16, 2000 at 12:05:14AM +0100, Simon Cozens wrote: > On Sun, Oct 15, 2000 at 04:59:50PM -0400, Jorg Ziefle wrote: > > Detailed information should follow soon. Should I write an RFC to > > discuss about, though I would come a bit late? :( > > RFC 313 not good enough for you? :) I think that's a pre-requisite for Jorg's idea. Even when (er, if) RFC 313 is accepted, someone's got to maintain the localized strings. That's mostly the issue Jorg had brought up. While it's still useful to translate perl*.pod today, it's important that we design/build Perl6 to be localized from Day 1. Z.
Re: how the FreeBSD project gets its "core members"
On Sat, Oct 14, 2000 at 10:33:57PM -0700, Stephen Zander wrote: > One question: how does an individual become a committer in the first > place? This question becomes of upmost significance to folks like > David Grove :) Submitting patches that are accepted into the tree are a huge part of it. Here's a page from the website: http://www.freebsd.org/tutorials/committers-guide/article.html and the relevant section: http://www.freebsd.org/tutorials/committers-guide/conventions.html That page doesn't discuss the process of going from user-with-patches to committer-with-mentor. Z.
Re: how the FreeBSD project gets its "core members"
On Fri, Oct 13, 2000 at 05:00:10PM -0500, Jarkko Hietaniemi wrote: > On Fri, Oct 13, 2000 at 04:35:42PM -0500, Jarkko Hietaniemi wrote: > > http://www.bsdtoday.com/2000/October/News306.html > > Oops, sorry about that, didn't read Ziggy's message first... > No worries. These BSD guys are onto something. Here's another report from daemonnews, talking about the election process in more detail. Apparently, FreeBSD was getting stagnant, and this election is a way for them to get new blood and more community involvement in the project. http://www.daemonnews.org/200010/dadvocate.html Z.
On Working groups, WGC, etc.
The FreeBSD Core team has just finished electing their next core team. Only "significant" contributors to the project were allowed to vote, and those elected hold office for a fixed term (two years). The Core Team of nine members determine the project's goals and directions. Many open source projects seem to work in a similar manner. Announcement of the election: http://daily.daemonnews.org/view_story.php3?story_id=1263 [Old] Core Team description: http://www.freebsd.org/handbook/staff.html Contributors (e.g. Cast of Thousands): http://www.freebsd.org/handbook/staff-committers.html List of responsible parties: http://www.freebsd.org/handbook/staff-who.html Z.
Re: Now and then
On Wed, Oct 11, 2000 at 09:41:30AM -0600, Nathan Torkington wrote: > Then again, remember the hassles we had with the perl6-* lists? > Nobody knew how to deal with topics that overlapped lists. You had > to know all the groups to decide which it was appropriate for. Are > these big enough hassles to suggest that perhaps the perl5-porters > All In One list wasn't such a bad idea after all? Perhaps. Even though there was a lot of traffic, much of it was easy to follow because a significant proportion of it was consistently titled - RFC ## (v#): Add XYZ into Perl. That traffic is also easy to find in the archives. That will probably be less of an issue with a strong lack of RFC activity during the implementation phase. It very well could be that anyone doing serious work is going to subscribe to perl6-all, and the perl6-* lists exist for those who just want to listen. Z.
Improving Perl6 RFCs (was: ...)
On Wed, Oct 04, 2000 at 11:00:55PM +0100, Simon Cozens wrote: > On Wed, Oct 04, 2000 at 03:42:57PM -0500, Jarkko Hietaniemi wrote: > > Too many RFCs live in a vacuum by not not explaining in enough detail > > what is the problem they are trying to solve, but instead go ahead and > > pull new/backward-incompatible syntax and/or keywords and/or semantics > > out of thin air. > > This skirts, but does not *quite* touch on, the *REAL* failure of the > RFC process. The real failure, as I see it, is this: We can only tell > whether an RFC is officially good or officially stoopid when Larry casts > his vote on it. And that only happens once all the RFCs have been > completed. *This* RFC process was about brainstorming, and about totally rethinking what Perl can be. It was designed to get the bizarre ideas out there (like currying and lazy evaluation) to see how we could best extend Perl. The *next* RFC process (assuming there is one for the development of p6) will need to strongly discourage wild brainstorming and strongly encourage Real Work (tm), including real proposals on how to solve hard problems, which will find their way into implementation. It sounds like your request is to add a CFV mechanism to RFCs, once there are teams working on the various aspects of Perl6. Suggestions? (Hint: think about core teams.) > This makes it nearly impossible to build ideas on top of previous RFCs, > since you don't know if you're building on rock or sand; Assume the 362 RFCs in the repository don't exist. Assume that the few that are being accepted are part of a new RFC effort. And assume that those are solid, or are easily made solid. > To be more specific: Perl isn't something you can separate out into > discrete blocks; two proposals are very, very infrequently independent. There are going to be people focusing on QA, and others focusing on regexes. Discussing why one QA proposal has merit is orthogonal to its use on writing test cases for regexes. Once that QA proposal is accepted, it intertwines itself into regex test cases. Z.
Re: RFC Process Improvements (was Re: RFC 357)
On Wed, Oct 04, 2000 at 02:19:02PM -0700, Nathan Wiger wrote:
>
> And *possibly*: Somebody should be able to pre-scan them. Not for
> content ("bad idea"), but to make sure they fit the format and also
> don't rehash already open or previously covered issues.
The job of the RFC librarian is to make sure the submissions are in
the proper format.
An editorial process might be worthwhile for some groups but not
others. In any case, such review should be done by a WGC (or WGEditor).
Z.
Re: Update on the RFC Process
On Tue, Oct 03, 2000 at 08:50:24AM -0600, Nathan Torkington wrote: > Bradley M. Kuhn writes: > > It seems to me that the perl6-internals, perl6-qa, and perl6-licenses groups > > should be able to produce additional RFCs after this. Of course, the > > Language will be frozen, but these three groups may need to remain fluid > > after the 14 October 2000 annoucement. > > I think perl6-licenses should start to move towards a decision after > the 14th. Find something that there's a rough consensus for, write up > the pro-s and con-s, then give it to Larry. What about pending -licenses RFCs? Bradley has made a very good point that -licenses (and -qa?) aren't directly impacted by the language design and should be immune from the moritorium. Some of the -licenses RFCs could be considered "brainstorming". Most are better categorized as complete proposals for action and discussion. > I think -qa should continue. I don't know about RFCs, though. I see value in the RFC process. It generates more coherent discussion than when someone walks into a thread and says: You're all wrong. Perl should use the QPL. and promptly leaves, leaving an unproductive flamewar in his wake. I'm also in favor of having more stringent acceptance criteria on a per-group basis. For example, -qa may have a required test plan section, and -licenses may have a required redistribution section. These criteria could be drafted in a manner to reduce or eliminate pie-in-the-sky brainstorming RFCs for each group. > I'm still thinking about how best to encode the -qa group's output. Numbering each block of RFCs separately by working group would be one easy way of splitting brainstorming from licensing discussions (RFC #QA-1, etc.). Z.
Update on the RFC Process
The time for brainstorming about what Perl6 can/should be is coming to a close. As Nat posted recently, we are now entering a two week review period in anticipation of Larry's language design. >From this point forward, no new RFCs will be accepted until the RFC submission process is reopened. Any new RFCs that are submitted during this review phase will be held in limbo until new submissions start up again. For the next few days, only frozen and retracted RFCs will be sent through. This is intended to facilitate Larry's (and everyone else's) review of the 361 RFCs submitted to date. Thanks for your ideas and hard work everyone, Z.
Re: Undermining the Perl Language
On Sun, Oct 01, 2000 at 12:14:49PM -0500, David Grove wrote: > [...] I've no idea why Sarathy was deposed, He wasn't. > but I have a > pretty big suspicion. And a pretty big, well known problem with ActiveState. > The problem is, I love Sarathy too. He's a hero, Yes, he's pretty heroic. > now with > a tarnished reputation, You think his reputation is tarnished, because that forwards your anti-ActiveState beliefs. I daresay that you are the only one with such a belief, or such reason for that belief. > not necessarily solely because but definitely partially > because, of a poor choice in employers. "Definitely partially"? Logically, if his reputation isn't tarnished, then he didn't choose employers poorly. David, please take your conspiracies elsewhere. We've all heard them before and they are not germane to the Perl6 brainstorming process we find ourselves in right now. Z.
Re: *REALLY*, it's getting close here...
On Thu, Sep 28, 2000 at 07:56:49PM -0700, Daniel Chetlin wrote: > On Fri, Sep 29, 2000 at 12:56:44AM +0100, Simon Cozens wrote: > > Why isn't there a documentation w/g? Yes, this is a hint. > > My RFC 240 garnered exactly 0 responses, so there doesn't seem to be > much of an interest. I was trying to decide today whether I should > freeze or withdraw. I agree that there should be a documentation w/g, but I personally believe it is premature to set up such a group, since there is no perl6 to document. Z.
Re: *REALLY*, it's getting close here...
On Thu, Sep 28, 2000 at 05:01:06PM -0700, Stephen Zander wrote: > > "Stephen" == Stephen Zander <[EMAIL PROTECTED]> writes: > Stephen> Not necessarily. Nat recently posted about his > Stephen> misinterpretation of Larry's plans but said he still > Stephen> planned to lean on people to finish by October 1 > Stephen> otherwise they'd never get done. My expectation is that the RFC process will still freeze while Larry is examining the ~350+ submissions to date. There's going to be plenty to discuss when he comes out with the draft language design, so it's not going to be like there's nothing to be done after 10/1. I'd like to take advantage of the 2-week RFC freeze to focus on the process we set up for the first two months of Perl6. That way, we can start talking about more procedural issues, like what happens when someone comes up with v1 of an RFC but abandons it for 7 weeks. Does it become "Status: Dormant"? Or is it enough of an improvement over the p5p process to have a synopsis and a clear thread of discussion to start examining? "Go check last year's archives for this discussion" isn't as difficult with p6 as it has been with p5p. > Of course, I'm probably full of crap too... Ditto. :-) Z.
Re: You know what? I think I learnt something today.
On Wed, Sep 27, 2000 at 10:34:32AM +0100, Piers Cawley wrote: > Simon Cozens <[EMAIL PROTECTED]> writes: > > Which is what I'm working on. You'll all be extremely pleased to know, I'm > > sure, that I have notes here for another 12 RFCs. After that, I have to start > > thinking. > > Three days to go to the Big Freeze. Where are you going to find the > time? You seem to forget, Piers, that he's Simon Cozens. :-) Z.
UPDATE: Overdue RFCs
Perl6 RFCs: Overdue RFCs Report generated: Wed Sep 20 21:40:38 2000 GMT 265 RFCs submitted. 189 RFCs in development. 126 RFCs not updated within the last 7 days. perl6-language: 56 RFCs overdue perl6-internals: 18 RFCs overdue perl6-language-data: 10 RFCs overdue perl6-language-flow: 8 RFCs overdue perl6-language-regex: 8 RFCs overdue perl6-language-subs: 7 RFCs overdue perl6-language-objects: 6 RFCs overdue perl6-language-io: 5 RFCs overdue perl-qa: 3 RFCs overdue bootstrap: 1 RFCs overdue perl6-language-datetime: 1 RFCs overdue perl6-language-errors: 1 RFCs overdue perl6-language-strict: 1 RFCs overdue perl6-licenses: 1 RFCs overdue
Re: Deadline for all RFCs? If so, why?
On Tue, Sep 19, 2000 at 07:26:17PM -0400, Bradley M. Kuhn wrote: > I am curious if this applies to any Working Groups besides perl6-language. I don't see why not. We're nearing the 300 RFC mark, and most of the RFCs have yet to make it to v2. I don't think encouaging hit-and-run RFC submission was the intended goal, and I do think we want to draw these discussions to a close. > As chair of the Licensing Working Group, I am a bit concerned that we > haven't developed enough possible licensing proposals. I am happy to hustle > everyone to write more RFCs and get proposals on the table, but the deadline > does seem a bit arbitrary for anything but the language design itself. The Perl6 design process does not end on Oct 1, nor does it end on Oct 15. I feel confident that we'll revisit what happened over the first two+ months of brainstorming and improve upon it. That may mean semi-permanent working groups, and stronger deadline enforcement for temporary working groups. Licensing is one of those areas that won't be solved by Oct 1, but it's worthwhile to summarize the discussions -licensing has had over the past few weeks, so we don't spend the next few months rehashing pro-/anti-GPL holy wars. RFCs are also a library of old arguments that we don't want to get in the way of developing Perl6, not just recommendations for Larry to consider lazy evaluation and currying. > And, as for internals, it seems like that group will just get started when > the language freezes, so there doesn't seem any reason to freeze > internals-RFCs by the deadline, either. If that's the case, then there was no point in having an RFC process for -internals. Some of the internals issues have impacts on language design, though, as do some of the issues raised on -stdlib, etc. Z.
Re: 'Markers'/RFC prototypes
On Tue, Sep 19, 2000 at 08:47:11AM +0100, Piers Cawley wrote: > > That *shouldn't* be hard. If you're getting hung up on details like > > =over 4, =item, L<> and C<>, then leave them out. > > No, I'm getting hung up on the fact that it'll take a bunch of time to > flesh out the RFCs beyond a simple TITLE and ABSTRACT and I want to > get the idea on the table before the deadline. Then what's wrong with Nat's proposal? On Mon, Sep 18, 2000 at 10:18:41AM -0600, Nathan Torkington wrote: > > Why do you need to do this? Just post with a subject line like: > > IDEA: All Perl keywords should be in UPPER CASE > > and watch the shooting begin. Anything that survives this phase > can be RFCed. Z.
UPDATE: RFC Status
All RFCs must fall into one of three status categories: Developing (RFC is incomplete; commments requested) Frozen (Comments received; nothing more to say) Retracted (Comments received; author is removing idea from consideration.) (NB: 'Retracted' has many spellings, including 'Retired' and 'Withdrawn'.) As the Perl6 process evolves, other statuses may be created as needed. The idea-gathering phase of Perl6 needs to be wrapped up before the moritorium on RFC submissions. Therefore, I want to encourage RFC authors to move their submissions into a 'Frozen' or 'Retracted' state. "Frozen" does not necessarily imply "shall never be updated again", but rather "discussion has ended, and there doesn't seem to be anything more to say on this topic". Note that Frozen RFCs may be updated, so long as those updates are minor changes, such as clarifying existing points, or adding relevant references (other RFCs/mail messages/URLs). Major changes to frozen RFCs will be rejected or force the RFC back into a status of "Developing", in order to discuss those major changes. Z.
Overdue RFCs
In order to trim the large number of RFCs that have not been updated in many weeks, yet are still "in development", I've prepared a report of which RFCs are most overdue. http://dev.perl.org/rfc/overdue.html Here is the current status, broken down by group: Report generated: Tue Sep 19 07:06:51 2000 GMT * perl6-language: 60 RFCs overdue * perl6-internals: 18 RFCs overdue * perl6-language-data: 12 RFCs overdue * perl6-language-subs: 9 RFCs overdue * perl6-language-flow: 8 RFCs overdue * perl6-language-regex: 8 RFCs overdue * perl6-language-objects: 7 RFCs overdue * perl6-language-io: 6 RFCs overdue * perl-qa: 3 RFCs overdue * bootstrap: 1 RFCs overdue * perl6-language-errors: 1 RFCs overdue * perl6-language-strict: 1 RFCs overdue For the purposes of this report, "overdue" is any RFC that has not been modified in the last seven days. Any RFC that has not been modified in the last fourteen days is highlighted in red. The most overdue RFCs are shown first. Each working group has its own page, listing details for each "overdue" RFC. If you want to take your name off these lists, you know what to do. Z.
Re: Request for Clarification: RFC Statuses
On Mon, Sep 18, 2000 at 12:18:19PM -0600, Nathan Torkington wrote: > I'm against fractional version numbers on the grounds that it's > another piece of knowledge that must be held before someone can > understand the system (think of 5.004_54 and how hideous that system > was). Integers imply all changes are equal. I like that, and I'm not > sure that microupdates warrant this new level of complexity. I want to assert to the reader that there have been no substantive changes since v3 if an RFC was frozen at v3, but is currently v5. A "Frozen Since: v3" attribute should make this apparent. > My feeling: if the maintainer is: > * fixing typos > * adding References > then they should be allowed to update the frozen RFC, incrementing > the version number and describing the change in the Changes section. That works, and keeps the spirit of "frozen". Z.
Re: Request for Clarification: RFC Statuses
On Mon, Sep 18, 2000 at 02:04:51AM -0400, Bennett Todd wrote: > 2000-09-18-01:35:42 Adam Turoff: > > Background: RFCs should be in development until frozen or retired. > > An interesting puzzle. As the author of RFC 70, I've felt like I > should make some updates, but they've been utterly trivial, mostly > just citing other relevent RFCs, or adding a smigeon of detail > thanks to tchrist's list of non-wrappable builtins. Thanks, Bennett. I have my answer. >From here on out, Frozen RFCs shall remain Frozen. Should the maintainer wish to clarify them after they have been frozen, the version number will increment by some fractional value (.01?), and a "Clarified: DD MMM " header will be added to the metadata. Objections? I think it's time to encourage RFCs to be frozen. Hopefully this will help. Z.
Re: Request for Clarification: RFC Statuses
On Mon, Sep 18, 2000 at 10:12:33PM +1100, Jeremy Howard wrote: > Some background would help--how is Larry being fed these RFCs? By pointing his browser to http://dev.perl.org/rfc/. Just like the rest of us. I seriously doubt he's using Grail or tkWeb as his browser though. :-) Z.
Re: Request for Clarification: RFC Statuses
On Mon, Sep 18, 2000 at 02:18:50AM -0400, Michael G Schwern wrote: > On Mon, Sep 18, 2000 at 01:35:42AM -0400, Adam Turoff wrote: > > Background: RFCs should be in development until frozen or retired. > > > > Problem: Frozen RFCs are being updated. > > Solution #4: Slip the RFC status back to 'developing'. I'd rather not. That appears to invite more discussion when we're trying to wrap things up. > If someone updates a frozen RFC, its obviously developing again. Or it was obviously frozen prematurely. > The > new RFC will require review. Then the maintainer can change the > status back to frozen, or continue updating. According to http://dev.perl.org/rfc/by-group.html (and by-number.html) there are 207 RFCs that are currently under development. (The number is actually closer to 220; Damian seems to have sent over a dozen RFCs in the last 12 hours or so.) The whole point of having frozen RFCs (and cleaning everything up prior to 10/1) is to reduce the number of ideas out there in the ether that are unfinished or up for discussion. > 'Biologists have a term for things which are stable. It is "dead".' Which reminds me, Jarkko has some RFCs which appear to be "stable". ;-) Z.
Re: 'Markers'/RFC prototypes
On Mon, Sep 18, 2000 at 10:18:41AM -0600, Nathan Torkington wrote: > Piers Cawley writes: > > The idea here is to allow people to get ideas on the lists in a rough > > form where they can get some initial comments (which may blow the > > 'real' RFC out of the water...). There should be some very strict > > rules about how soon the 'real' RFC arrives though. > > Why do you need to do this? Just post with a subject line like: > > IDEA: All Perl keywords should be in UPPER CASE > > and watch the shooting begin. Anything that survives this phase > can be RFCed. If the issue is trying to get ideas fleshed out in the next week, adding yet more structure (e.g. proto rfc) would keep those ideas from being posted. The RFC format is intended to impose as little format and structure as necessary to the author, while presenting an appropriate amount of format and structure to the reader. Once you've got a description, the next things to do are summarize it in an =head1 ABSTRACT, add in some thoughts on migration issues and implementation details, and finally, references to other RFCs, man pages or mail messages (so people have an idea where you're coming from). (Don't forget the title and version sections, which should be quite easy.) That *shouldn't* be hard. If you're getting hung up on details like =over 4, =item, L<> and C<>, then leave them out. Z.
Request for Clarification: RFC Statuses
Background: RFCs should be in development until frozen or retired. Problem: Frozen RFCs are being updated. -- Solution #1: Ignore updates to frozen/retired RFCs Solution #2: Allow frozen/retired RFCs to be updated, if the status is unchanged. Solution #3: Allow frozen/retired RFCs to be updated, but only if the update further clarifies the RFC -- There are currently some RFC updates in the queue that update frozen RFCs. Once again the progression is: Developing /\ Frozen Retired (or Withdrawn or Retracted) || (No futher discussion required) New statuses may appear, such as "Accepted" and "Rejected", but it is premature to talk about that until Larry actually starts accepting or rejecting RFCs (should he so choose). A status change from "Frozen" to "Retired" may be acceptable. Such updates would indicate that discussion came to an end on a topic, and subsequent discussions caused the author to remove that idea from consideration. So, what's everyone else think? I really don't want to write up an RFC about this. :-) Z.
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
On Fri, Sep 15, 2000 at 04:11:27PM -0600, Nathan Torkington wrote: > Mark-Jason Dominus writes: > > I think it would be a step in the right direction if the WG chairs > > actually required RFC authors to maintain their RFCs. > > In preparation for the end-run of RFCing, how about we compile a list > of "developing" RFCs that haven't been touched in more than a week, > and contact the authors to say "last chance, please finish up your > RFC now." > > Such a program would be easy to write (praise be to Date::Parse) and > would hopefully prod authors into incorporating feedback and closing > out their RFCs. > > Good idea? [time passes] I didn't use Date::Parse, but I did look for all RFCs still stting at v1 status. Since they're numbered chronologically, I cut off the bottom (anything submitted after 9/7). There are 100 RFCs in the list that follows. Code and data upon request. Z. - RFC : 3 v1; [Developing] Title: messages.rfc - An RFC to discussing the wisdom of allowing run time error and warning messages to be modified at run time Maint: Corwin Brust <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 1 Aug 2000 RFC : 7 v1; [Developing] Title: Higher resolution time values Maint: Gisle Aas <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 2000-08-02 RFC : 9 v1.0; [Developing] Title: Highlander Variable Types Maint: Andy Wardley <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 01 Aug 2000 RFC : 11 v1; [Developing] Title: Examples encoded with =also for|begin|end POD commands Maint: Barrie Slaymaker <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 02 Aug 2000 RFC : 12 v1; [Developing] Title: variable usage warnings Maint: Steve Fink <[EMAIL PROTECTED]> for now List : [EMAIL PROTECTED] Date : 2 Aug 2000 RFC : 13 v1; [Developing] Title: Creation of Copyright and Licensing Working Group Maint: S E[EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 2 Aug 2000 RFC : 15 v1; [Developing] Title: Stronger typing through tie. Maint: Michael Fowler <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 02 August 2000 RFC : 16 v1; [Developing] Title: Keep default Perl free of constraints such as warnings and strict. Maint: Daniel Chetlin <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 3 Aug 2000 RFC : 18 v1; [Developing] Title: Immediate subroutines Maint: Jean-Louis Leroy List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 19 v1; [Developing] Title: Rename the C operator Maint: J. David Blackstone <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 Aug 2000 RFC : 20 v1; [Developing] Title: Overloadable && and || Maint: Jean-Louis Leroy List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 21 v1.00; [Developing] Title: Replace C with a generic C function Maint: Damian Conway <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 22 v1.00; [Developing] Title: Builtin switch statement Maint: Damian Conway <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 24 v1.00; [Developing] Title: Semi-finite (lazy) lists Maint: Damian Conway <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 25 v1.00; [Developing] Title: Multiway comparisons Maint: Damian Conway <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 27 v1; [Developing] Title: Coroutines for Perl Maint: Tom Scola <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 28 v1 ; [Developing] Title: Perl should stay Perl. Maint: Simon Cozens <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : Aug 4 2000 RFC : 31 v1.00; [Developing] Title: Co-routines Maint: Damian Conway <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 32 v1; [Developing] Title: A method of allowing foreign objects in perl Maint: Dan Sugalski <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : August 02, 2000 RFC : 35 v1; [Developing] Title: A proposed internal base format for perl variables Maint: Dan Sugalski <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : August 04, 2000 RFC : 36 v1; [Developing] Title: Structured Internal Representation of Filenames Maint: Jarkko Hietaniemi <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 40 v1; [Developing] Title: Module Scope Control Maint: Bryan C. Warnock <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 5 Aug 2000 RFC : 43 v1; [Developing] Title: Integrate BigInts (and BigRats) Support Tightly With The Basic Scalars Maint: Jarkko Hietaniemi <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 05 Aug 2000 RFC : 44 v1; [Developing] Title: Bring Documentation Closer To Whatever It Documents Maint: Jarkko Hietaniemi <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 05 Aug 2000 RFC : 46 v1; [Developing] Title: Use features of portable, free compilers and libraries Maint: John Tobey <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 5 Aug 2000 RFC : 47 v1; [Developing] Title: Universal Asynchronous I/O Maint: Uri Guttman <[EMAIL PROTECTED]> List : [EMAIL PRO
Re: The Future - grim.
On Mon, Sep 11, 2000 at 11:49:52PM -0500, J. David Blackstone wrote: > > On Mon, Sep 11, 2000 at 11:34:55PM -0500, J. David Blackstone wrote: > > > > Presumably the discarding will be heralded with an announcement on the > > mailing list, as well as a note to the maintainer. The interested > > parties should see this and yell. > > Just wanted to get that stated explicitly. I hope "heralded" gives > enough time to those of us who would like to adopt orphaned ideas. I just want to state for the record that I won't be taking any unilateral action on orphaned RFCs. My current thinking is identifying RFCs that have had no activity in 3+ weeks, mailing the maintainer and relevant WG asking for a status update. If there is no update and no interest in the RFC, that RFC is deemed "orphaned" after one week. If the maintainer doesn't say anything and a new champion is found, then maintenance switches to the new champion. If the original maintainer says *anything at all* about the RFC (including private email), then nothing happens (absent updates). Finally, I'd like to point out that no WGC seems receptive to the idea of instituting a Last Call process, so this discussion is pretty much moot. My feeling is that it's up to the WGC to decide how the last call process works, and my outline above is merely a suggestion. Z.
Re: The Future - grim.
On Sun, Sep 10, 2000 at 09:58:14PM +0100, Alan Burlison wrote: > I don't believe in magic. I'm an engineer by profession, not an > astrologer. However, I will predict endless arguments when some of the > less than coherent proposals are rejected. The RFC process was intended to bring out both good and bad suggestions. On the positive side, there's interest in currying. On the negative side, we have some half baked proposals, some of which frequently appear on p5p every year or so. At least with an RFC archive, those fruitless flame wars can be stopped quickly by citing a relevant rejected RFC than they are today by saying "go look in the mailing list archives." > [...] I > suggest you do the blindingly obvious - look at the current p5p'ers, > figure out who has contributed in each area of interest and ask those > folks to form a team to work on the same area in p6. If new people want > to contribute, fine, but they should be integrated into an existing team > rather than be sent off to 'do their own thing'. A possible suggestion > is an apprenticeship approach - ask potential contributers to take on a > substantial but not critical-path part of the work, get them to complete > it and then have it reviewed by the other members of the team (you are > going to code reviews - right?) If everyone is happy then they can be > invited in. >From this, I can extract these action items: 1) Set up p6 development like other open source projects, where there is a "core team" responsible for the progress of Perl6 or a component of Perl6. These people have write access to the source repository (whatever it may be). 2) Set up an explicit path for sometimes contributors to submit patches, new code, new docs and new tests. 3) Set up an explicit path for apprenticeship. This should lead to membership in the core team for trusted apprentices who have proven themselves as being capable and reliable. Code/doc reviews are one metric for proving oneself to the core team. 4) Set up closed mailing lists for the core team to post onto, that are made available through read-only open subscription to the community at large. These lists should have a policy established to accept worthwhile postings from non-core members (simple forwarding works; moderation works). > > What we're doing about that: > > * pushing the output through Larry > > [Yes, this addresses only part of the problem. Any suggestions for > > other ways to solve this?] > > The RFC mountain is way, way too high to be climbed by just one person, > let alone the output of the various mailing lists. What about a litlle > good old-fashioned dictatorship, or at least a Junta? All of the RFCs have mailing lists associated with them, and all of the mailing lists have chairpeople leading discussion. Why not ask these chairpeople to start a Last Call process, whereby any unmaintained RFCs can be marked as "unmaintained and withdrawn" by the relevant WGC. That should cull out a bunch that haven't been updated since being posted one month ago. Especially the dubious ones. It would have been nicer to institute this policy from the start, but no one expected to get 200 RFCs in just over one month, either. Z.
Re: code repository
On Fri, Sep 08, 2000 at 10:24:05AM -0400, Bennett Todd wrote: > I'm really sorry to see people so anxious to favour commercial, > proprietary tools, even in this arena, [...] It isn't about favoritism. It isn't about commercial vs. open source. Perl is a pragmatic language. Perforce is a pragmatic choice. That's why it's used for Perl5, and that's why those who patch Perl prefer it. Z.
Re: code repository
On Thu, Sep 07, 2000 at 05:31:37PM -0400, Bennett Todd wrote: > 2000-09-07-17:11:50 Dan Sugalski: > That's certainly possible, but since the reason we're gathered here > together working on trying to launch perl6 is a collective belief > that perl5 has become unmaintainable for further development, [...] and the reasons for that lack of maintainability are *entirely* due to the codebase, *NOT* tools used to maintain that codebase. > > [...] given how many branches are active, perforce seems to be a > > win. > > Given that it's only available to people who happen to run supported > platforms, OK. That pegged the fud-o-meter. The list of supported platforms listed on http://www.perforce.com/perforce/loadprog.html is hovering around fifty, including boutique architectures for Linux, NetBSD and FreeBSD, as well as three versions of VMS, two architectures of BeOS, Amiga OS, four versions of Solaris/SunOS, [...] So, to summarize: 1) Perl6 development will be *open* to anyone able to diff, patch and send/receive those patches. 2) A very small number of developers will have write-access to the master Perl6 repository. This is comparable to most other open source projects using BitKeeper, CVS or Perforce. 3) Those developers prefer Perforce and should not be forced to use CVS because non-committers prefer it. 4) Perforce clients are *freely available* and *supported* on a wide range of platforms. No, it's not open source, and that is regrettable. 5) The use of Perforce is a pragmatic choice. If the requested features *were* available with CVS, then CVS would be used instead of Perforce. 6) An anon CVS interface to the Perl6 source tree should be made available for public consumption, synchronization, etc. How this is implemented is left as an exercise for those with the tuits. [*] Is there anything more to be said about Perforce vs. CVS that *isn't* FUD? Z. *: Sarathy tells me that Perforce sucks at maintaining thousands of anonymous checkouts, while CVS doesn't mind at all. This is a perfect reason to use anon CVS vs. Perforce, but does not require that Perforce be ditched in favor of CVS, only that an anon CVS gateway be maintained.
Re: code repository
On Wed, Sep 06, 2000 at 12:14:17AM -0400, Bradley M. Kuhn wrote: > Dan Sugalski wrote: > > The decisions should be based on technical merit and general availability. > > I would include "available under a free software license" as part of the > definition of "general availability". Bradley, your argument against perforce really sounds like you're saying your uncomfortable with non-free software in general, not with perforce in particular. I haven't heard a reason to switch to CVS yet[*]. > For example, perforce doesn't ship standard with operating system > distributions such as Red Hat, Debian, and FreeBSD, because it isn't under a > free software license. However, CVS does ship with those systems. There's a p4 client in the FreeBSD ports tree, and if I were to check my FreeBSD 4.1 distribution set which arrived yesterday, I'd probably find a package all ready to install. No, it's not a souce distribution, but it's bundled with FreeBSD in the same way that python, Gnome and qmail are. > Also, what if people want to learn how the source system works on their own, > and experiment with it? http://www.perforce.com has freely downloadable clients and 2-user servers. Most people learn how to use CVS on local repositories, and I don't see why Perforce would be any different. > With only 100-user license, we are pretty tight as > to who can do that. There are probably more than 100 people on the various > perl6 mailing lists who'd want to at least experiment with the system on > their own. People shouldn't be playing around in the Perl repository to learn Perforce. And 100 users is a *lot*. Many free software projects are running CVS with fewer than 100 users with write access to the repository, and a mechanism for a random contributor to submit patches and contributions without having write access. Why should Perl be any different? Z. [*] The biggest reason IMNSHO to use CVS is to encourage people to hack the source; more people know and use CVS on a daily basis than use perforce, at least in the free software community. That said, maintaining a mirror in CVS would accomplish that for anonymous access, as would a perforce-to-CVS gateway. Both approaches are being discussed.
Working Group Summaries online
http://dev.perl.org/summary/ Each established list/working group has a spot on this page. Weekly/Bi-weekly summaries will be posted as they arrive. Currently, only the two summaries from last week (Aug 31) are online. Earlier summaries will be posted as I find them in the archives (or as they are forwarded to me :-). Please cc perl6-librarian on future working group summaries. Comments welcome. Z.
Re: RFC Updates
On Thu, Aug 31, 2000 at 07:08:38PM +1100, iain truskett wrote: > * Adam Turoff ([EMAIL PROTECTED]) [31 Aug 2000 17:41]: > > A handful of long overdue updates to http://dev.perl.org/rfc have been made: > [...] > > - More detailed summaries of all RFCs are available, organized by > > RFC number and working group. See http://dev.perl.org/rfc/by-number.html > > and http://dev.perl.org/rfc/by-group.html > > Perhaps have by-date.html as well? [sorted by date of last submission > --- most recent at top] Not today. There is no standard date format for RFCs yet, and I don't want to start hacking around with Date::Parse or Date::Calc just yet. What would you want to see there? The RFCs are numbered in chronological order already. Do you want to see the RFCs sorted in terms of what was most recently posted or updated? Z.
Re: RFC Updates
On Thu, Aug 31, 2000 at 08:02:36AM -0400, David Corbin wrote: > > Comments, criticisms, etc. welcome. > > > > Can you put a legend explaining the color code on the pages where the > colors are used? Look again. Next request? ;-) Z.
RFC Updates
A handful of long overdue updates to http://dev.perl.org/rfc have been made: - All RFCs are now maintained in both POD and HTML. HTML conversion is courtesy of pod2html. - More detailed summaries of all RFCs are available, organized by RFC number and working group. See http://dev.perl.org/rfc/by-number.html and http://dev.perl.org/rfc/by-group.html - Detailed views associate non-developing RFCs by color: - Retracted/Withdrawn/Retired RFCs are in pink. - Frozen RFCs are blueish. - RFCs with no explicit status are identified as "[Developing]". NB: Retratcted/etc. denotes that the maintainer has removed an RFC for consideration for one reason or another. Frozen denotes that the issue raised by this RFC has been discussed fully and there appears to be nothing more to say on the topic; it does not imply acceptance, rejection or a concensus view on the RFC. Comments, criticisms, etc. welcome. Updates to dev.perl.org/rfc/meta are scheduled for later this week. Z.
Re: RFC format
On Wed, Aug 30, 2000 at 04:35:31AM -0400, Bradley M. Kuhn wrote: > My patch had other changes, too, that we cam to a consensus on. Any chance > they'll be added, or is Ziggy just plain too busy? ;-) Ziggy is busy, and he's working on having the by-number.html, by-group.html and by-author.html pages up and running today. Check out dev.perl.org/rfc/rfc.tbl and rfc/by-number.html if you want a peak. Fixing meta/* is on tap for tomorrow or Friday, depending on when my packages arrive from UPS tomorrow. Z.
Re: Proposal for IMPLEMENTATION sections
On Wed, Aug 30, 2000 at 04:04:03PM -0400, Mark-Jason Dominus wrote: > > Suppose a WGC establishes a requirement for the solidity of the > implementation section, and receives an RFC that does not meet the > requirements. What then? > If the WGC chair sets forth explicit requirements as to what goes into the implementation section, then any RFC that does not meet those requirements will be put on hold or rejected for cause and sent back to the author (with a CC to the WGC). Currently, any RFCs that do not meet the low formatting requirements are put on hold or rejected for cause and sent back to the author. In both cases, an RFC will be accepted when fixed. Ditto for other requirements. Starting tomorrow, Status: fields will be manditory, and all new RFCs will default to 'Status: Developing' if omitted. Z.
Re: Proposal for IMPLEMENTATION sections
On Wed, Aug 30, 2000 at 02:29:33PM -0400, Mark-Jason Dominus wrote: > > > Any requirements on how solid an implementation section should be > > should be left to the working group chairs. > > Sorry, I don't understand this. What is the WGC's role here? My english native language is? :-) I meant to say that if there are to be more stringent requirements as to what should be in an implementation section, I leave that decision to the WGC. It's not the job of the librarian to reject an RFC because it lacks sample code, but if the WGC wants to be stricter, I will try and abide on a per-group basis. Z.
Re: Proposal for IMPLEMENTATION sections
On Tue, Aug 29, 2000 at 07:34:10PM -0700, Nathan Wiger wrote: > Mark-Jason Dominus wrote: > > > > The IMPLEMENTATION section of the RFC is supposed to be mandatory, but > > there have been an awful lot of RFCs posted that have missing or > > evasive IMPLEMENTATION sections. > > Well, I have to counter this with the following: Having a complete > IMPLEMENTATION section should wait until at least v3. Then there are the "position paper" RFCs that don't require an implementation. Simon's RFC 28: 'Perl should stay Perl' is a perfect example. And don't forget the "really cool new ideas" where a discussion of implementation is premature, like Damian's RFC 21: 'Replace C with a generic C function'. Both of these should have a stub, but should never be expected to have a full implementation, v3 or otherwise. > So I would say, v1's and v2's should get some slack. If the idea's still > around by v3, then IMPLEMENTATION should be considered. But doing this > before them is a waste of time, IMO. Yes, there should be some slack, but not on the reqirement to have an implementation section. I would hope from here on out, RFC authors spend a modicum of time writing up why an idea doesn't need an implemenation, why such discussions are premature, or why the author needs help writing it up. Any requirements on how solid an implementation section should be should be left to the working group chairs. Z.
Re: Proposal for IMPLEMENTATION sections
On Tue, Aug 29, 2000 at 06:26:29PM -0400, Mark-Jason Dominus wrote: > > I'd like to amend my proposal. Suppose that the librarian *suggests* > that RFC authors contact the WG chair when they submit RFCs that omit > the implementation section? That way nobody is forced to do anything, > and many people might be grateful for the service. > Consider this done, starting 9/1. Status headers will become manditory as well. There are about 25 RFCs and updates in the queue at the moment that should be exempt. Waiting until Friday gives everyone at least one day's notice. The dev.perl.org/rfc/meta section is long overdue for an update. Thanks to everyone who has sent patches, recommendations, and questions about the RFC format. I hope to get to it this afternoon, after posting today's lot of RFCs. Note that this does NOT mean that RFCs will be rejected outright. To date, authors of incomplete RFCs have been contacted when their submissions cannot be posted as-is, so that their submissions may be completed. Z.
