Leaving the Parrot nest
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:
- source code repositories (note: plural)
- web sites
- blog / news
- wiki
- issue tracking
- mailing lists
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):
- Rakudo.org is run by Andy Lester and currently provides a "blog" for Rakudo Perl. Andy has mused about switching rakudo.org to Drupal instead of Movable Type, which could enable us to more easily have "introductory content" information instead of just blog-type entries.
- Of course, many of us regularly post to journals at http://use.perl.org/ . This is good for keeping in touch with the wider Perl community and provides a good blog-like interface, but again isn't useful at basic Rakudo information and orientation.
- The Perl Foundation hosts a "Perl 6 wiki" at http://www.perlfoundation.org/perl6/index.cgi?perl_6 , and Rakudo has a few pages there. Currently I find the wiki to be not very well organized, and it's difficult to find Rakudo out of the many other items that appear there. Beyond that, I'm not impressed with the wiki engine the site uses, but if a sizable group of people think that's where Rakudo information should be centered then I can live with it.
- TPF also hosts the "Perl 6" website at http://dev.perl.org/perl6/ , but "Rakudo Perl" isn't even mentioned there, and I don't even really know the correct procedure for getting updates or modifications to those pages. My impression is that this site isn't really conducive to frequent updates or lots of contributors (but perhaps I'm incorrect about that).
- Planet Perl 6 (http://planetsix.perlfoundation.org(approve links)) is an excellent aggregator of Perl 6 related posts, including those involving Rakudo Perl.
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
5 Comments
Subscribe
-
Subscribe to rakudo.org
There's already a discussion about that topic on the perl6-compiler mailing list, so if you want to share your thoughts, post there.
Badly needed and thanks for taking it on. It is really messed up at the moment -- I always have to do double-checks when I'm trying to access synopsis and other standards from the web to make sure I'm on the site with the up-to-date stuff. I realize that's perl6 not rakudo-specific, but any effort to comb out this hairball would be great.
There are plenty of half-starts to "getting everything organized" and they end up adding to the confusion. There's little in the way of being able to search for your interest and being helped along with a "go here read these" for those of us who like to do a little homework before asking a question.
Make up a question about rakudo and try a google search. It ain't pretty.
I've seen drupal and well to be frank I think wikis are better than all of these CMSs. It may have yellow teeth but I've found TWiki to be nice what with the flexibility to restrict access to certain areas but leave others free. The world needs a Wiki with a really good inter-user trust and authority system (heck the world needs a good trust system beyond just authentication) -- it just seems to be petting the cat backwards to the wiki philosphy.
Anyway back on topic another problem I have is I have very little patience for mailing lists -- prefer wiki and forums and chat -- and as far as IRC goes you have parrot, where if you ask a question about perl6 you're told to go to #pugs, and you have #pugs where well hey that works in pugs but not rakudo. It isn't bad since often #parrot folks will deign to answer questions anyway, but if at some point you have an influx of new devels who like IRC, a rakudo-specific IRC channel might be something to think about.
Now that rakudo "feature status" was a good idea but how will people find it? What I'd do is make that a question on a FAQ, which implies having a FAQ, which would probably imply reviewing old ml's, blogs, and chat records and deciding what questions are actually frequently asked (or by inference, what people do not seem to be picking up that they should really have known just from perusing publicly available materials.)
I think it highly practical to make the infrastructure for rakudo autonomous and self-contained so that people do not have to use different resources to communicate with parrot.
I also think switching away from RT is a good idea, a lot of module writers never visit RT and it has an outdated interface.
Thanks for the post.
As an average Perl user (programmer) who has been watching the development of Perl 6/Parrot/Rakudo with interest, I thought I would chip in with a few comments.
Source code repository
You said, "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."
Perl users (like me) are really programmers, so even if they aren't involved in developing Perl, they are involved in developing with Perl. So we are developers anyway and source code control system are probably not bothered about having a couple of source code control systems installed.
I would rather that those who are doing the developing of Rakudo used the tools that best suited their neeeds.
That said, for downloading something to play with, I would rather have tarballs (nightlys and/or regular milestone releases). If they had everything needed to get going all in the one file, then even better!
The easier you make it for people to try out, the more people will. But that, to my mind, is a different issue to using git or svn.
Web site / blog / wiki
It would be really great to have a central and authoritative website for all things Rakudo (if there was a website that was central and authoritative for all things Perl 6 - that would be even better)!
My key suggestions are:
- make it look good
- provide a clear introduction and entry point for newcomers
- keep it up-to-date
- avoid jumping around different domains (eg. wiki, blog, docs, forum, etc.)
- plan for being multi-lingual
You managed to get parrot.org (very impressive), who owns perl6.org? Apart from that, I think running Drupal on rakudo.org would be a great solution.
I know TIMTOWTDI and all that, but I think it would be worthwhile to abstract multiple implementations of Perl 6 from newcomers at least a bit. Rakudo is "THE Way Of The Camel" - don't be afraid to promote it!
Steal some good ideas from other websites:
- http://php.net/ (regardless of what you think of PHP, their online docs are great)
- http://www.ruby-lang.org/ (it looks nice, of course I'm going to 'digg' it)
- http://www.python.org/ (good intro and about page)
Virtually all Perl websites are ugly (apart from the new Parrot site), please don't let it happen again. It's only a small investment to make a website look nice. Have a design competition or something.
Cheers,
Ross
skids1 said:
"I've seen drupal and well to be frank I think wikis are better than all of these CMSs."
I've seen TWiki and well to be frank I think CMSs are better than all of these wikis. :)
Wikis do have their place, and can be great when done well, but they do not work well in all situations. Most wikis I have seen are ugly, unorganised and have poor information.
Anyway, the whole website does not need to be all wiki, or all CMS, but it would be good to have a fairly integrated approach to the various features that might be needed:
- CMS
- Blog
- Wiki
- Discussion Forum (I agree that a forum would be good)
Drupal does all of these things, and is generally regarded highly (although it is a bit weak on the wiki side of things).
My vote would be for using Drupal.