Re: Update on the RFC Process
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. I wrote up nearly all the ideas brought up. I put the last RFC in just under the wire (that was RFC: Perl6's License Should be the same as the modified BSD license), but it was refused, sadly. Save the RFC that didn't make it in time, I don't think there were any other viable ideas that aren't already RFC's. So, what Larry needs to see is there. The only additional changes would be for legal reasons once we bring some lawyers in. So, I'd say the working group has submitted everything that Larry needs to see (if the "under the wire" RFC mentioned is added). -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: Update on the RFC Process
On Tue, 03 Oct 2000, Simon Cozens wrote: > On Tue, Oct 03, 2000 at 04:06:00PM +0100, Piers Cawley wrote: > > Personally I'm betting that the volume we've seen on -language will > > pale into tiny insignificance compared to the volume on -internals > > once Larry has made his announcement. > > I doubt it; I think we've a lot of people who want to talk about how > Perl should be. I don't think we'll have *that* many people when it > comes to actually trying to implement those ideas. Particularly since -internals will... er, should be focused on one direction, vice the pell-mell that -language has been. Discussions will also require some deeper supporting arguments - something more than "It'll be cool" or "I want it that way" - which should also help reduce traffic. (Other than requests for more information or explanation, which, I sincerely hope, will be tolerated and answered, as opposed to ignored or flamed. Hint hint.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Update on the RFC Process
At 04:26 PM 10/3/00 -0400, Adam Turoff wrote: >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. I'd personally like a license chosen before any code gets written in earnest, so that might well argue for -license to wrap up before then. (Whether this is an issue or not is up in the air--it depends on who's submitting code) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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.
Re: Update on the RFC Process
At 04:13 PM 10/3/00 +0100, Simon Cozens wrote: >On Tue, Oct 03, 2000 at 04:06:00PM +0100, Piers Cawley wrote: > > Personally I'm betting that the volume we've seen on -language will > > pale into tiny insignificance compared to the volume on -internals > > once Larry has made his announcement. > >I doubt it; I think we've a lot of people who want to talk about how >Perl should be. I don't think we'll have *that* many people when it >comes to actually trying to implement those ideas. I'm with Simon on this. The set of people with the skills and time to design or implement the core is significantly smaller than the set of folks who think they can redesign some (or all) of the language. The discussion's also likely to be more focused and less grumpy. I hope... :) If we look at p5p, most of the traffic at any one time revolves around design issues, not implementation. (Barring the runup to a release, when the volume's more in OK/NOK messages) I expect the same will be true for us, though I expect the volume of internals design traffic to be smaller than that for language design. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Update on the RFC Process
On Tue, Oct 03, 2000 at 04:06:00PM +0100, Piers Cawley wrote: > Personally I'm betting that the volume we've seen on -language will > pale into tiny insignificance compared to the volume on -internals > once Larry has made his announcement. I doubt it; I think we've a lot of people who want to talk about how Perl should be. I don't think we'll have *that* many people when it comes to actually trying to implement those ideas. -- "He was a modest, good-humored boy. It was Oxford that made him insufferable."
Re: Update on the RFC Process
Nathan Torkington <[EMAIL PROTECTED]> writes: > I have no objection to -internals remaining. I think their discussion > will probably take off more after Larry's announcement. Personally I'm betting that the volume we've seen on -language will pale into tiny insignificance compared to the volume on -internals once Larry has made his announcement. -- Piers
Re: Update on the RFC Process
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. I think -qa should continue. I don't know about RFCs, though. I think we'll need some way to separate the brainstorming RFCs on language from the methodology RFCs on -qa. I see QA having a strong say in how we develop the software: reviews, test cases, and so on. I'm still thinking about how best to encode the -qa group's output. I have no objection to -internals remaining. I think their discussion will probably take off more after Larry's announcement. Nat
Re: Update on the RFC Process
Nathan Torkington wrote: > Adam Turoff writes: > > 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. > When were you thinking the RFC process would reopen? I wouldn't want to > see the brainstorming start up again until it's time to start thinking > about 6.1. It might have benefit in refining ideas prior to development, > though. 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. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: Update on the RFC Process
Adam Turoff writes: > 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. When were you thinking the RFC process would reopen? I wouldn't want to see the brainstorming start up again until it's time to start thinking about 6.1. It might have benefit in refining ideas prior to development, though. Nat
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.
