Re: code repository
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". > You would, but in this case I don't. We can give anyone we want a client > and get them access to the repository. You can give people a client, but it may not be something they are able to use. I do understand the concern from the other side---that the technology of perforce is better. My point is that even if the technology is better, some people will be alienated by a proprietary software source revision system. I am not in a position to really influence the decision one way or the other; I just wanted to voice my concern that I (and others with my beliefs) will have to be a second-class perl6 developer if proprietary software tools are required to be a first-class perl6 developer. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: code repository
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 "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. Yes, that is my argument. I don't think we should have key, required tools in the development chain for perl6 be proprietary software. I would have nothing against perforce if they release it as free software. > I haven't heard a reason to switch to CVS yet[*]. Thanks for making some. ;) > > [*] 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. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: code repository
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 merit and general availability. I think it's terribly, terribly depressing, even worrisome, to hear someone in this locale implying that open source availability is a purely political attribute, and not a technical one with a very important and direct bearing on availability. 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 the primary motivations for this investment of time and effort here on the perl6-* lists was the problem that far too few people can contribute to perl5 development. That being the case, the claim that perl5 uses a tool doesn't qualify as a strong argument in favour of that tool. Perhaps perl5's use of perforce isn't a contributor to its problems that have us here working on a rewrite. Could be. But are there any major open source projects working on perforce that _aren't_ trying to re-invent their development processes due to a perceived failure of same? -Bennett PGP signature
Re: code repository
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 many cases before > > writing the code, and to seriously consider trying to write unit tests for > > pretty much every bit of code that you write. They have a catchy slogan for it. They call it the test --> code --> design development cycle. Of course, the design phase is characterized exclusively as 'refactoring', since they're primarily concerned with Smalltalk. But even in a big sprawling project like this, 'refactoring' isn't a bad one-word description. Also, don't you want to refer more to 'unit tests', rather than regression testing, when talking about small pieces of code inserted in pod sections close to each piece of program code. Certainly, these pieces can be automatically collated in clever ways to attempt effective overall coverage, but the immediate reward for the programmer you're trying to entice to use it, is that she can fire off that '=for testing' snippet every time she touches that code. This is the big win that the XP people emphasize. for anyone interested/curious/befuddled: http://c2.com/cgi/wiki?ExtremeProgramming http://c2.com/cgi/wiki?CodeUnitTestFirst
The casino or just plain bizzare?
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
Re: code repository
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 the primary motivations for this investment of time >and effort here on the perl6-* lists was the problem that far too >few people can contribute to perl5 development. Perl 5's development issues have nothing to do with the code repository--given how many branches are active, perforce seems to be a win. The problems perl 5 has are almost entirely due to a code base that has reached past the end of its useful life. Perl 6 development is open to anyone with perl source, a text editor, a compiler and a copy of diff. (And for good code I'll generate the fscking diffs myself if I can get a copy of the changed source) *Nobody* needs *any* repository tools to play this game. Period. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: code repository
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 further development, citing perl5 as an example of how a given tool is just what we need to be using seems shaky at best. 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? > [...] 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, who are willing to run random binaries from untrustworthy sources, _and_ that we're at the mercy of a private company for bug-fixes and maintenance, it seems like it'd be more prudent to let people who really like perforce feel free to use it themselves for their private tracking, but to avoid wiring it into the heart of the distributed development of perl6 as a whole. -Bennett PGP signature
Re: code repository
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 source from the proposed anon CVS mirror. If you've got a better alternative with a proven track record (and the only alternatives I know of that rival it all cost) put it on the table, please. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: code repository
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 been greatly exaggerated. I'm sure you know that already, and I think you could have been more careful with your choice of wording. Alan Burlison
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 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 sweeping architectural decisions early in the project, allow you to recover from bad design decisions and return flexibilty to old code. It may be good for rapid development projects, but I don't think we should apply it to Perl. We have a very good idea of what our requirements are (especially compared to most software out there), a solid prototype to work from (perl 5), and some very solid ideas of what the architecture should be. Furthermore, I don't think there are any refactoring tools for C. I've only heard of them for Java and Smalltalk (maybe C++). > Of course, the design phase is characterized exclusively as > 'refactoring'... For the record... "Refactoring" is only one tool used in that design philosophy. Unfortunately, its apporaching buzzword status lately and the test->code->design approach you mentioned and the technique of refactoring are kind of ooozing together in the public's perceptions. I'd like to point out that they are seperate entities. Refactoring is simply the automated alteration of code without effecting its purpose. A simple example would be reversing the order of arguments in a subroutine. A refactoring tool would be able to do this for you automatically and in all code which uses that subroutine. Handy. It does this by defining a set of simple operations which a refactoring tool must be able to perform. From those simple operations, it can do much more complicated things. Unfortunately, Perl's dynamic nature makes most refactoring impossible. Furthermore, refactoring loses much of its power when applied on Open Source libraries since you are no longer in control of all code which uses said library. In a controled environment, you can alter interfaces to your heart's content. With Open Source, if you alter a function's interface you may break the code of hundreds of programs. Still, it has its uses and can be helpful in localized parts of the code. I've been going through the catalog of refactorings and trying to determine what can currently be done in Perl and how much change in Perl it would take to reimplement the rest. It doesn't look good, but I'll publish what I've got once its complete. Martin Fowler wrote a book "Refactoring: Improving the Design of Existing Code" http://www.refactoring.com/ Bill Opdyke's original thesis paper on the subject is here ftp://st.cs.uiuc.edu/pub/papers/refactoring/ > Also, don't you want to refer more to 'unit tests', rather than > regression testing They could be called "Mr. Wosabe tests" for all I care. Terminology was never my strong point (above rant is the rare occasion). :) -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Work like hell, tell everyone everything you know, close a deal with a handshake, and have fun. -- Harold "Doc" Edgerton
Re: The casino or just plain bizzare?
>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/bezroukov/index.html Very interesting; hard to autoagree with all of that, but plenty to nod your head to. --tom
Re: code repository
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 also designed for the situation where you're trying to hit a moving target (customer keeps changing requirements). Because we're essentially the customers for this project, I think we're in a good position to be able to follow the specifications->design->code. The thought that we may be the only people in a position to do that scares me. That sounds too good to be true. It doesn't scare me as much as the prospect of starting coding without designing. The perl6-* experience has shown that it'll never end if we don't cut off features at some point. 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 control, in other words. This all adds up to not following the continuous refactoring approach to design. In short, I agree :-) Nat
Re: code repository
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 control, in other words. 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. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse When faced with desperate circumstances, we must adapt. - Seven of Nine
Re: code repository
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 division of effort scares me. It's an interesting concept, that manpower might be infinite in the Open Source World, but I'd rather everyone agreed to stick to implementing what is in the design as a first priority. Adding a new feature would require documentation, test cases, and analysis of how the feature fits in with the umpty-zillion other features in Perl, not just code. I figure the lead coder can look at progress, look at the new feature, and decide whether it's worth it on a case by case basis. But I am cool to the idea that we should lose good coders to potentially bad ideas. Explore those ideas later, get perl6 working first. Nat
Re: code repository
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 sketch out what you're thinking of (Perforce plus CVS, several committers, whatever it is) and give us a few use cases. How does some random person submit a patch? How does someone claim a unit to code? How do people stay current? Then we can hear informed criticism and perhaps modify the plan if a better system is suggested. Nat
Re: code repository
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.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Maybe they hooked you up with one of those ass-making magazines. -- brian d foy as misheard by Michael G Schwern
Re: code repository
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 going to make it > > into the next release they can branch and play. > > Adding a new feature would require documentation, test cases, and > analysis of how the feature fits in with the umpty-zillion other > features in Perl, not just code. I figure the lead coder can look > at progress, look at the new feature, and decide whether it's worth > it on a case by case basis. > > But I am cool to the idea that we should lose good coders to > potentially bad ideas. Explore those ideas later, get perl6 working > first. Its not good feature/bad feature. Its more like parallel development. Take, for example, threading. The tailors decide they need to overhaul the guts of threading yet again, but the Pumpking is concerned that it would hold up the next release to wait for the new threading code to be stable. So a branch is made and the threading boys go off and play with their threads and the rest of Perl gets on with it. A release or two later, the threading branch is ready and is rolled into the main release. 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 new bugs. There is a problem of integration. Each track will have to pay attention to what the others are doing, and they can't go too long without merging back into the main branch else there will be too many conflicts. But I think overall the problems of bugs via features interacting will be lowered due to the fact that when branches are merged back into the main that branch has already been tested on its own and works. The same patching and testing rules would apply across all "official" branches (if somebody wants to go nuts on their own we can't really stop them) and QA would keep an equal eye on them all. In effect, all feature patches would happen in branches, and nothing but bug fixes should appear in the main. In fact, I'd almost go so far as to say a new branch should be made for each bug to be fixed. These branches would be short lived, but they would help to consolidate the series of bug fix patches which is often applied to fix a single bug. Make them easier to track and know when a bug has been officially closed (the branch has been merged). Of course, all this comes from someone who doesn't know how to branch in CVS. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Plus I remember being impressed with Ada because you could write an infinite loop without a faked up condition. The idea being that in Ada the typical infinite loop would be normally be terminated by detonation. -- Larry Wall in <[EMAIL PROTECTED]>
Re: code repository
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 to end the debate after a reasonable time period. List: [EMAIL PROTECTED] Chair: Dan Sugalski <[EMAIL PROTECTED]> Deadline: 18 September 2000 Mission: To decide the source control system (Perforce, CVS, etc) to be used for perl6 development. Dan's chair not because I want to stack the odds in favour of one thing over another, but because he's been taking the lead in source issues so far. Ask, please work your mailing list magic. Thanks, Nat
Re: code repository
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 new bugs.
I think we're talking different scenarios. This implies there already
is code. I've only been talking about the first version of perl6,
getting it out the door. The existing pumpkings have had plenty of
experience with branches ("fork" is such a dirty word :-) in the source
tree, and can give advice on how it works when you already have code.
I view branches in this initial version as highly unlikely to be
useful. We need to have a trunk before we can have branches.
Nat
Checkpoint
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 RFCs. The need for RFC versioning and status, and the structure of the RFC list should have been in place from the get-go. I'll never again agree to run something and go on vacation :-) That didn't work well: the initial kerfuffle and misunderstandings could have been headed off had I or others who were at the meeting been around to explain things. Then again, I did try to explain things to people, and that didn't work either. Perhaps some confusion and hubbub is always going to be present, because people distrust change. On the positive side, there are good ideas being RFCed as well as bad ones. And there is an end to this brainstorming phase in sight :-) People have generally been courteous and respectful of one another, and those who weren't became so. Any more? I'm keen to learn from mistakes (preferably those of others, but my own will do in a pinch :-). Nat
Re: code repository
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 to have branches. I want to take some more time to write this idea out better, but the idea is basically to break alot of the interdependeness of the various pieces of perl (hashes, arrays, scalars, regexes, etc...) and develop each as a largely seperate library suitable for seperate release. This removes the need for a large hunk of perl6 to be working before we can get something useful. It should make the internals much cleaner, make testing easier (as we can test each piece before its integration), make things easier to document, make perl core hacking more approachable for newbies and produce a large amount of code libraries which could be used outside of perl. Let me write this out completely before anyone really tears into the idea. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse gumballs have no paste Tim's balls are so damn pasty bend over and squeal -- |siv|
Re: Checkpoint
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 until you get home. Had we sat on it for a week before making a public announcement strategic people would have been back at their computers to head off the shock and confusion that errupted. Of course, then Larry wouldn't have had his thunder. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse But why? It's such a well designed cesspool of C++ code. Why wouldn't you want to hack mozilla? -- Ziggy
