Dan Sugalski wrote:
> At 12:14 AM 9/6/00 -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".
Adam Turoff wrote:
> 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 "genera
2000-09-05-10:53:25 Dan Sugalski:
> >I don't think it's a good idea to build Perl6 development
> >infrastructure around non-free software.
>
> I don't think we should make decisions about the software we use
> for development based on political views. The decisions should be
> based on technical
Michael G Schwern wrote:
>
> On Sun, Sep 03, 2000 at 09:05:07PM -0700, Russ Allbery wrote:
> > I also think this may well be a good place to apply one of the ideas of XP
> > (Extreme Programming, a fairly flexible small-group software design
> > methodology), namely to write test cases *first* in
I found the following reference in the p5p archives to a paper
discussing open source development. I think this should be mandatory
reading for anyone contemplating a contribution to the RFC mountain.
http://www.firstmonday.dk/issues/issue4_10/bezroukov/index.html
Alan Burlison
At 11:49 AM 9/7/00 -0400, Bennett Todd wrote:
>2000-09-06-10:51:35 Dan Sugalski:
> > >Finally, most free software and open source projects have
> > >standardized on CVS. Do we really have a compelling reason to go
> > >against the standard?
> >
> > Perl 5 uses perforce, [...]
>
>I thought one of t
2000-09-07-17:11:50 Dan Sugalski:
> Perl 5's development issues have nothing to do with the code
> repository -- [...]
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 fu
Bennett,
Perforce is a better source code control system than the source
alternatives, and certainly better for the task we face than CVS.
You're certainly not forced to use it. You can, if you rather, grab
snapshot archives, rsync from the repository directory, or even grab a copy
of the sou
Bennett Todd wrote:
> So I ask again: do any _other_ projects,
> preferably ones that aren't regarded as procedural failures that
> need re-inventing from scratch, used perforce? Or is perl5, whose
> failure has brought us out today, its one poster project?
I think reports of perl5's death have
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
On Thu, Sep 07, 2000 at 01:49:36PM -0400, Peter Allen wrote:
> They have a catchy slogan for it. They call it the
>
>test --> code --> design
>
> development cycle.
That sounds bad. I've heard about this style. Code now, refactor
later. Its supposed to avoid the need for swe
>I found the following reference in the p5p archives to a paper
>discussing open source development. I think this should be mandatory
>reading for anyone contemplating a contribution to the RFC mountain.
Amongst other things, amongst other things
>http://www.firstmonday.dk/issues/issue4_10/
Michael G Schwern writes:
> That sounds bad. I've heard about this style. Code now, refactor
> later. Its supposed to avoid the need for sweeping architectural
> decisions early in the project, allow you to recover from bad design
> decisions and return flexibilty to old code.
Well, yes, but a
On Thu, Sep 07, 2000 at 10:15:38PM -0600, Nathan Torkington wrote:
> The hard part is probably going to be resisting the urge to add
> features just because they're possible: once we come up with a design,
> we must code the design, and leave new features for later 6.x
> releases. Feature creep c
Michael G Schwern writes:
> There's one solution, now that we have a nifty source control stuff.
> Branch like mad! Feature creep should be discouraged, but if a group
> wants to go off and work on something which isn't going to make it
> into the next release they can branch and play.
That divi
Adam Turoff writes:
> 3) Those developers prefer Perforce and should not be forced
> to use CVS because non-committers prefer it.
>
> Is there anything more to be said about Perforce vs. CVS that *isn't* FUD?
You make it sound like we've decided on Perforce. Dan, how about you
sk
On Thu, Sep 07, 2000 at 10:52:18PM -0600, Nathan Torkington wrote:
> Then we can hear informed criticism and perhaps modify the plan if a
> better system is suggested.
Could we split this off into a working group and mailing list seperate
from perl6-meta?
--
Michael G Schwern http://www.p
On Thu, Sep 07, 2000 at 10:48:57PM -0600, Nathan Torkington wrote:
> Michael G Schwern writes:
> > There's one solution, now that we have a nifty source control stuff.
> > Branch like mad! Feature creep should be discouraged, but if a group
> > wants to go off and work on something which isn't go
Michael G Schwern writes:
> Could we split this off into a working group and mailing list seperate
> from perl6-meta?
Sure. I'm going to set an aggressive schedule for the decision,
though, because this has all the hallmarks of a religious war. Let's
work through the problems now and be forced
Michael G Schwern writes:
> In effect, instead of having one development track, we could have many
> development tracks, each focused on a single feature, or small group
> of features. This should make work easier, because on each track only
> one thing is changing, so its easier to track down ne
So we're three weeks away from the end of this. I've been thinking
about where we went right and where we went wrong (and in particular,
what I would do differently if I had it to do again).
The biggest thing is that I underestimated the volume of traffic. I
never thought there'd be so many RFC
On Thu, Sep 07, 2000 at 11:14:34PM -0600, Nathan Torkington wrote:
> I view branches in this initial version as highly unlikely to be
> useful. We need to have a trunk before we can have branches.
I was actually speaking of both the initial development and on from
there. You don't need a trunk
On Thu, Sep 07, 2000 at 11:55:17PM -0600, Nathan Torkington wrote:
> Any more? I'm keen to learn from mistakes (preferably those of
> others, but my own will do in a pinch :-).
How about: If you make an earthshaking decision on day three of a
conference, do not announce it on day five. Wait unt
23 matches
Mail list logo
