Sorry for the 'tldr' reply...

On Jan 14, 9:01 pm, pmich...@pobox.com (Patrick R. Michaud) wrote:
> 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.

I assume you're saying the parrot project will be moving from
svn.perl.org to its own repo somewhere on the parrot domain.

> 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/.

I propose a restructuring/divestiture of the pugscode and
rakudo code repositories, as follows:

1. Centralize/reorganize the implementation-independent/agnostic
resources, documentation, and tools under a new repository, which
could be hosted at one of the perl6-related domain names I have,
such as git:// (and http(s)://www.perlsix.org/git/perl6 for
git-http-*), with automatic one-way (or two-way! with user
impersonation) replication/mirroring to svn and/or bzr on
launchpad.net/perl6.  This repo would include both the human-
readable (!) language specifications, and the machine-
readable/testable language specifications (the spec tests),
the standard grammar and its related tools, any global prelude,
and all the other implementation-nonspecific items.  The current
pugscode user accounts can be migrated to whatever backs the
authentication.

2. Leave the current svn.pugscode repo as is (except for the
items listed above), so that all the other implementations and
Perl6-related miscellany stored there can be migrated over to new
repos as necessary.

3. Host the rakudo repository in git or whatever [else] is
selected following the same convention,
git/http(s)://www.perlsix.org/git/rakudo and
http(s)://www.perlsix.org/svn/rakudo  Use the same authentication
store as http(s)://www.rakudo[perl].org (see below)... perhaps
integrated with single-sign-on and unified-sign-on systems at
launchpad.net, OpenID, BitCard, etc.

> 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.

No, but for this use case, snapshots of the requisite Parrot
release and then the client for whatever scm system Rakudo uses
should be sufficient, since the spectest suite can be hosted in
the same format, even if merely a one-way mirror.

> 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.

As the site of a major implementation of a multi-implementation
programming language, the www.rakudo(perl).* site(s) need to be
similar in content to the sites, for the following use cases:
www.ruby-lang.org
www.python.org
www.php.net

1. Obtain/Develop-ish category
   a. Download binaries/installer links
   b. Linux/BSD distribution/packages links (deb, rpm, launchpad)
   c. Build-from-source walkthrough (including dependencies)
   d. Contributor/developer initiation/training
      (1) git/svn training/walkthrough
      (2) bug-tracking system (launchpad.net?) links/tutorial
      (3) mailing list descriptions
   e. Spec-test progress/history/graphics
   f. Release announcements, developers' blog
   g. IRC links, logs
   h. gitweb and/or SVN::Web intefaces
   i. PCT tutorials/documentation
4. Discover-ish category
   a. Rakudo documentation, tutorials
   b. [Links to] Perl 6 documentation, specifications, tutorials
   c. User/community support forums & mailing lists
      (exposed through http, smtp, and nntp)
   d. Links to and/or aggregates of other/related blogs
   e. Links to Perl Foundation & development/benefactor news
   f. Link to www.perl.org or replicate much of its content
   g. Interactive web terminal to try out rakudo, "live"
   h. Links to sites/projects using rakudo

I recommend hosting this site on the WebGUI CMS on a VPS I'll
provide; I'll also provide a $30/year GoDaddy SSL certificate in
perpetuity for privacy/security, though since it's an open-source
project, the first year of the SSL cert may be free from GoDaddy.
I have a VPS where the site (including all SCM repos) could be
hosted; others' VPSes could provide backup destinations.

One option is to set the http://www.rakudo.org page to redirect
to http://www.perlsix.org/rakudo, where all the above content
can be hosted in an integrated site on WebGUI.  The biggest
benefit of this would be the SSL certificate cost savings.

I would use the built-in CMS features to delegate/administer the
maintenance of the site's content; the WebGUI web application
platform supports "staged"/"RC" revision sets of all content, and
is written in Perl (mod_perl/apache2/mysql5).  There are lots of
other features of WebGUI that would be useful to such a site (read
up on it!).  But by far the most attractive feature for this
application is its easy Perl
extensibility/pluggability/customizability.  The content can be
styled centrally, with the built-in rich text editor (TinyMCE)
pulling styles from stylesheets for point-and-click styling of
pages, though raw HTML is also accepted.  All changes are
versioned, backed by the database, and can be rolled back if
necessary.

> 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.

Migrate its entries to the Rakudo news blog; borrow the style. ;)

> * 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.

Aggregate [comment-nodes for] these on www.rakudo*.*

> * 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.

This can continue in its current form, as a not-quite-
authoritative source of information on various Perl 6
implementations.

> * 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).

This can be replaced with redirects to a new site that allows
easier updates on the WebGUI CMS: www.perlsix.org, which would
be an implementation-independent home for the Perl 6 language,
with much of the same (or shared, if the sites are integrated)
content/structure as listed above for the Rakudo site, but of
course implementation-nonspecific.

> * Planet Perl 6 (http://planetsix.perlfoundation.org) is an
>   excellent aggregator of Perl 6 related posts, including those
>   involving Rakudo Perl.

This can be proxied/mirrored on the rakudo*.* site(s), or
merely left as-is.

> 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
> athttp://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.

The forum system in WebGUI is fairly good (if it's styled nicely),
especially its SMTP integration.  New (emailed) threads can be
configured to create new "issues", to which file attachments or
replies can be added using either SMTP or HTTP uploads, just like
similar email-integrated forums.  I think it also supports issue
merging and referencing.  An NNTP interface could be added with a
bit of work.  I recommend also considering using Ubuntu's central
launchpad.net for the Rakudo bug-tracking system.  It wouldn't be
as integrated (authentication, identity) as using the same site,
but the bug-tracking and other project management features are
quite nice.  On launchpad my account is the owner of the rakudo &
perl6 projects, so we can appropriate those resources, which
would also of course ease the eventual ubuntu/debian packaging &
distribution.

> Mailing list
> ------------
> Currently Rakudo's primary mailing list is <perl6-compi...@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.

I disagree; I think Rakudo needs its own mailing list(s) in
addition to the implementation-nonspecific perl6-compiler list,
as it's currently named (the name should be made plural?):
1. A (new-)user-support/help mailing list/forum
2. A mailing list/forum for Rakudo developers
3. A Rakudo announcement mailing list/forum/blog (which in WebGUI
   are [based on] the same Wobject)

> 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.

I'm not married to [m]any ;) of these suggestions/ideas, so I
don't expect to be disappointed, hurt, or defensive about their
debunking or non-adoption. :D

> 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

Sorry for expanding the thread to include the Perl 6 web properties
ideas in addition to the Rakudo proposals.  I registered those
domain names originally exactly for this purpose (for the Perl 6
language and its implementations to have homes), so I'm excited
that they could be used for that purpose.  I hope you all catch
my implication that all the other Perl 6 implementations could &
would have similar hosting opportunities available and provided.

-Matthew Wilson (diakopter)
diakop...@gmail.com

Reply via email to