As many of you will have gathered from discussions on other mailing lists and IRC, it's time for Rakudo Perl to "leave the Parrot nest" and move to its own repository. I think we should also take this opportunity to re-evaluate the entire Rakudo Perl infrastructure and decide what will be most productive for the community for the upcoming year. Indeed, as part of any move we need to communicate the details of the changes to others, which brings to the surface some of the shortcomings of what we have now.
By "infrastructure" I'm primarily referring to the following items:
Currently these things are spread in many different locations with different tools, and while I don't believe it's necessary for them completely unified, we should at least aim to reduce the overall complexity of what we do have so that we can better serve those who are interested (or are yet to become interested) in Rakudo Perl. In fact, it may be that in many cases we'll keep what we have now, but at least it'll be a confirmed decision instead of simply going along with what we've had in the past.
Also, I'm sure it will be easy and tempting to address larger issues about Perl 6 as a whole (as opposed to just "Rakudo"). I'm not at all opposed to seeing that larger discussion take place, but for my purposes I'll be tending to focus on Rakudo's immediate needs.
Here's my off-the-cuff inventory of where things are in Rakudo today and where things might head. It's entirely possible that my description below misunderstands or misrepresents reality in some areas -- but I'm dedicating this week to resolving that. Indeed, that's the primary purpose of this message, to help us all clear up confusion surrounding Rakudo (and Perl 6).
Source code repository
This is the immediate issue at hand, because we need to move Rakudo out of the Parrot repository so that it can cleanly move to its new home at parrot.org. Currently Rakudo Perl lives at http://svn.perl.org/parrot/trunk/languages/perl6/ , while the spectest suite (on which development/testing depends) lives at http://svn.pugscode.org/pugs/t/spec/ .
Many people have strongly suggested that we switch to using "git" as our version control system. At the moment I'm neither strongly in favor of nor strongly opposed to switching version control systems, but we have to recognize that at least two of Rakudo's "dependencies" (Parrot and the spectest suite) are using Subversion and are likely to remain that way for a while. We don't want to require non-developers to install a lot of different source code control systems simply to run and test the latest incarnation of Rakudo Perl.
I have a lot more comments on source code management for Rakudo Perl, but to keep to the "overview" nature of this post I'll save the rest for a longer post. Feel free to start submitting your opinions, however!
Web site / blog / wiki
Currently Rakudo really does not have a dedicated website providing basic information about it. There is the http://rakudo.org/ site, but it's currently more of a blog than a true web site. For example, someone visiting rakudo.org would not be able to easily find out how to download and run Rakudo Perl.
Here's what we do have at the moment (as best as I can recall):
Also, for the record, I currently own the "rakudoperl.org" and "rakudoperl.com" domains, so if we want to do something somehow separate from any of the existing domains cited above, we can use those domains, and I may have (or be able to acquire) additional server resources to support it.
Issue tracking
Currently issue tracking for Rakudo is being done using RT at http://rt.perl.org/ (the same RT instance that does Perl 5 bug tracking). In the past I've stated that Rakudo bugs will continue to use this tracker, and I'm still planning for that to be the case, but in recent weeks I've encountered a number of times were rt.perl.org was too slow/unreachable to be an effective tool. I'm not (yet?) advocating that we switch to a different issue tracker, but since we're looking at the whole of infrastructure items I did want to leave the possibility open for discussion.
Mailing list
Currently Rakudo's primary mailing list is <perl6-compiler@perl.org>. I see no major reason to change anything here, as it works well and is a good companion to the other "official" Perl 6 mailing lists.
----------
Throughout all of this, I'm looking at things from a very practical perspective -- i.e., what can we achieve with the resources currently at our disposal. It's also important to consider the needs of the various audiences -- not only the Rakudo developers, but also people who want to experiment with Rakudo and those who want to start building applications for it. So, we need to keep in mind the many perspectives on the issue as we go through the discussion.
Also, I'm expecting that some of the decisions I eventually make may disappoint some; apologies in advance, but such is the nature of decisions.
With that background in place, I'll now (with great trepidation) open the discussion for others to comment and/or make suggestions of what they'd like to see changed about the way we currently manage Rakudo Perl.
Thanks in advance,
Pm
Earlier today on the IRC channel, Will Coleda made an interesting comment regarding partcl.
07:28 <@Coke> I'd rather have folks go to
That makes a lot of sense. So, have you given much thought to how you want to enforce and/or manage the version of Parrot you will be running Rakudo under? I think this may be an important issue. Given how much breakage we see in languages still in the parrot repository, I worry that decoupling of parrot from rakudo will only make the "moving target" problem worse.
Presumably, Rakudo itself is in the best position to define which version(s) of Parrot it expects to run under. So do you think there should be some kind of startup sanity check? Or going even farther, a "make parrot" target which (if the appropriate version of parrot isn't found on the system) goes and fetches it, unpacks and builds it?
Re:Parrot management
pmichaud on 2009-01-15T17:25:16
I've just posted a reply to this comment on the perl6-compilers mailing list -- when perl6.org's mailing list manager catches up it should appear here.
(It seemed more useful to put it on the mailing list than to try to keep separate threads on use.perl, rakudo.org, and the mailing list.)
Pm
Thank you for this thorough and temperate summation of the issues. I don't follow Rakudo or Perl 6 that closely; I barely have tuits to follow Parrot. So I don't have much to say one way or the other about how Rakudo's infrastructure should evolve.
I just wish we had had a blog post like this concerning Parrot's infrastructure before all these changes started happening.
Thank you very much.
Re:What are our constraints?
pmichaud on 2009-01-15T14:29:00
I agree that knowing about constraints is important; that said, I haven't been able to come up with any limitations or constraints along the lines you've mentioned that I think are insurmountable.
Pm
Re:mod_perl6 dependencies
pmichaud on 2009-01-15T17:26:23
I'm thinking we might be able to eliminate the Parrot checkout for many/most projects. Maybe not mod_parrot itself, but who knows?
Pm
Re:mod_perl6 dependencies
duff on 2009-01-15T18:29:37
This sounds like one place where svn:externals can be put to good use. You could make an "umbrella repository" that gets all of the proper revisions of all the required pieces and to the outside universe, it'll be just a single "svn checkout".
MT4 can easily be used to create standard "web pages" in addition to a blog.
