A hosting proposal for Scala standard library incubator projects

What needs funding? Github and RunCodeRun are free for open source projects.

--j

On Sat, Sep 12, 2009 at 3:34 PM, Miles Sabin <miles@milessabin.com> wrote:

If we go down this route then my company would be willing to fund at
least the first year of operation (although obviously other
contributors would be very welcome).

To go ahead I'd like a thumbs up from Martin, and Alex, Heiko, Erik,
Paul and Josh (as likely leaders of the modularization, I/O and build
infrastructure working groups). I'd also like to have David's buy in.

Concretely I propose we,

* host code on github.
* use github's issue tracker.
* use a service like RunCodeRun[1] for builds.
* use google groups for discussion.

Subject to a signed Scala Contributor License Agreement[2] commit and
posting rights would be given to,

* anyone actively involved in a Scala standard library working group.
* any current committer to the main EPFL tree.

All code would have to be published under the Scala License[3]. No
other strings attached.

I suggest we try this out for practicality using the free account
options of the various services and then upgrade to an appropriate
paid plan if it looks like it's going to work out in practice.

Let me know what you think ...

[1] http://runcoderun.com/
[2] http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf
[3] http://www.scala-lang.org/node/146

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

I'm not 100% convinced that RunCodeRun can provide the goods for this, especially given the fragile versioning issues that Scala has.
Perhaps we can take up David on his offer in part, and stick with GitHub and the EPFL licence, but use the existing hudson installation on Scala-Tools.  One benefit here is that it's already compiling the Scala svn trunk and deploying it to a local nexus installation.
In the meantime, I'm also researching the best way to configure hudson and maven for cross-compiling scala projects against different library versions, as deployed in a Maven repository.


On Sat, Sep 12, 2009 at 11:34 PM, Miles Sabin <miles@milessabin.com> wrote:

If we go down this route then my company would be willing to fund at
least the first year of operation (although obviously other
contributors would be very welcome).

To go ahead I'd like a thumbs up from Martin, and Alex, Heiko, Erik,
Paul and Josh (as likely leaders of the modularization, I/O and build
infrastructure working groups). I'd also like to have David's buy in.

Concretely I propose we,

* host code on github.
* use github's issue tracker.
* use a service like RunCodeRun[1] for builds.
* use google groups for discussion.

Subject to a signed Scala Contributor License Agreement[2] commit and
posting rights would be given to,

* anyone actively involved in a Scala standard library working group.
* any current committer to the main EPFL tree.

All code would have to be published under the Scala License[3]. No
other strings attached.

I suggest we try this out for practicality using the free account
options of the various services and then upgrade to an appropriate
paid plan if it looks like it's going to work out in practice.

Let me know what you think ...

[1] http://runcoderun.com/
[2] http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf
[3] http://www.scala-lang.org/node/146

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Miles, I think the idea is good.
As David may have mentioned (we were emailing off list) by attaching to Lift, it would help in situations (such as scalax) where the community/interest begins to fizzle.
I'm still mulling which option is better, but I'll contribute where needed regardless.

Kevin - 
Responses below.
Sent from my iPhone
On Sep 12, 2009, at 7:49 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I'm not 100% convinced that RunCodeRun can provide the goods for this, especially given the fragile versioning issues that Scala has.
Perhaps we can take up David on his offer in part, and stick with GitHub and the EPFL licence, but use the existing hudson installation on Scala-Tools.  One benefit here is that it's already compiling the Scala svn trunk and deploying it to a local nexus installation.

Actually, the scala svn trunk is compiled by EPFL's Hudson servers and pushed to scala-tools.org
David, if such an approach were taken, would you support them with scala-tools Hudson?

In the meantime, I'm also researching the best way to configure hudson and maven for cross-compiling scala projects against different library versions, as deployed in a Maven repository.

I wouldn't spend too much time in maven.  It does it's best to make versions in dependencies immutable (after it finds the version).
The best I could come up with involves properties and some kind of tool/script to call maven for each supported version.
Also remember that to support 2.7.x and 2.8.x should require different source code (unless you don't use the new features.

On Sat, Sep 12, 2009 at 11:34 PM, Miles Sabin < (miles [at] milessabin [dot] com> wrote:

If we go down this route then my company would be willing to fund at
least the first year of operation (although obviously other
contributors would be very welcome).

To go ahead I'd like a thumbs up from Martin, and Alex, Heiko, Erik,
Paul and Josh (as likely leaders of the modularization, I/O and build
infrastructure working groups). I'd also like to have David's buy in.

Concretely I propose we,

* host code on github.
* use github's issue tracker.
* use a service like RunCodeRun[1] for builds.
* use google groups for discussion.

Subject to a signed Scala Contributor License Agreement[2] commit and
posting rights would be given to,

* anyone actively involved in a Scala standard library working group.
* any current committer to the main EPFL tree.

All code would have to be published under the Scala License[3]. No
other strings attached.

I suggest we try this out for practicality using the free account
options of the various services and then upgrade to an appropriate
paid plan if it looks like it's going to work out in practice.

Let me know what you think ...

[1] http://runcoderun.com/
[2] http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf
[3] http://www.scala-lang.org/node/146

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

On Sat, Sep 12, 2009 at 11:56 PM, Jorge Ortiz wrote:
> What needs funding? Github and RunCodeRun are free for open source projects.

Possibly nothing, but if we need any of the paid-for premium options
I'm willing to fund them.

Specifically, the RunCodeRun paid for service provides dedicated build
resources which might mitigate Kevin's worries.

Cheers,

Miles

On Sun, Sep 13, 2009 at 12:49:37AM +0100, Kevin Wright wrote:
> I'm not 100% convinced that RunCodeRun can provide the goods for this,
> especially given the fragile versioning issues that Scala has.

Not sure if anyone knows I got scala going on runcoderun a while ago.
It took a few go-arounds with them to get the tools in place so scalac
would compile, but eventually I had it building successfully.

http://runcoderun.com/paulp/scala

However I never got around to setting up the running of the tests. All
in all I would say that while they were helpful in making the changes
necessary to get scalac building, I am skeptical that it would be very
satisfying to depend on someone else's infrastructure for testing (the
more so if we're open source freeloaders.)

As a supplement to something else, I'm all for it, which indeed is why I
started setting it up in the first place.

Also, I haven't heard good things about github's issue tracker, but
that's not a first-hand assessment.

Miles,  I like your proposal.  You have my support.
I think that:(1) It's important to be using the EPFL's contributor agreement.  I think that agreement should be tightened up, but I also think the Lift agreement is too tight, and based on my current understanding of it I would not sign it[1]. (2) It's important to use openly available hosted infrastructure.  Using GitHub + RunCodeRun would not only also us to work on Scala and have a build server, it would enable others who wish to experiment to reuse our configuration and do the same.  Being being downgraded to a free plan if money disappears. (3) If if it's too hard to use open infrastructure, I would suggest using EPFL infrastructure.  They do already have Hudson setup.(4) DPP has a big personality and runs a very tight (and successful) ship.  However, I'm concerned that there are several people who I consider critical that I think would find DPP's ship too constraining[2].
-Erik
[1] If the community does decide to go with Lift, I'll make an effort to get the agreement reviewed by an IP attorney so that hopefully either I can be made to feel comfortable with it or I can feed competent feedback to DPP. [2] Just in case anyone is wondering, I don't consider myself critical and the only part of DPP's ship that I find too constraining his IP agreement.

On Sat, Sep 12, 2009 at 6:34 PM, Miles Sabin <miles@milessabin.com> wrote:

If we go down this route then my company would be willing to fund at
least the first year of operation (although obviously other
contributors would be very welcome).

To go ahead I'd like a thumbs up from Martin, and Alex, Heiko, Erik,
Paul and Josh (as likely leaders of the modularization, I/O and build
infrastructure working groups). I'd also like to have David's buy in.

Concretely I propose we,

* host code on github.
* use github's issue tracker.
* use a service like RunCodeRun[1] for builds.
* use google groups for discussion.

Subject to a signed Scala Contributor License Agreement[2] commit and
posting rights would be given to,

* anyone actively involved in a Scala standard library working group.
* any current committer to the main EPFL tree.

All code would have to be published under the Scala License[3]. No
other strings attached.

I suggest we try this out for practicality using the free account
options of the various services and then upgrade to an appropriate
paid plan if it looks like it's going to work out in practice.

Let me know what you think ...

[1] http://runcoderun.com/
[2] http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf
[3] http://www.scala-lang.org/node/146

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

--
http://erikengbrecht.blogspot.com/

Erik Engbrecht wrote:
> (3) If if it's too hard to use open infrastructure, I would suggest using
> EPFL infrastructure. They do already have Hudson setup.

For the record I am currently looking into setting up a community-oriented
companion to scala-lang, hosted at EPFL, in order to have a usable
workspace for Scala-related projects that everyone can find and use.

Don't expect anything soon: designing and setting up a whole new system is
a long process, and the plan might go nowhere in the end, so I won't even
discuss that for the moment. Nonetheless, we are very much aware here that
the Scala community has a concrete need of a support infrastructure for new
projects, and we are doing what we can, within the time we have, to provide
a better service in the future.

Meanwhile, as several have observed, Google Groups and github served the
community well so far. Whether to use or not David's infrastructure is
something that you will have to decide on a project-by-project basis.
Toni

I must also say that David's infrastructure has been very, very kind to the Scala community.  All projects that have asked to be hosted on the maven repository have been added (AFAIK).  He even offers the use of hudson and statically hosted websites.  I'd love to see something integrated though, where all aspects of an open-source project that are needed are provisioned at once (by one provider), but where each component is actually nice stand-alone.

From previous experiece, gforge (open-source fork of sourceforge) turned out to be a blessing and a curse.  Having an integrated issue tracker/wiki/source control/mailing list/file release system was great.  The issue was most of the individual components were bad (the issue tracker was amazingly slow!). 

Anyway, good luck with the project!  Let us (the community) know if there's anything we can do to help.

On Sun, Sep 13, 2009 at 7:11 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

Erik Engbrecht wrote:

(3) If if it's too hard to use open infrastructure, I would suggest using
EPFL infrastructure.  They do already have Hudson setup.

For the record I am currently looking into setting up a community-oriented companion to scala-lang, hosted at EPFL, in order to have a usable workspace for Scala-related projects that everyone can find and use.

Don't expect anything soon: designing and setting up a whole new system is a long process, and the plan might go nowhere in the end, so I won't even discuss that for the moment. Nonetheless, we are very much aware here that the Scala community has a concrete need of a support infrastructure for new projects, and we are doing what we can, within the time we have, to provide a better service in the future.

Meanwhile, as several have observed, Google Groups and github served the community well so far. Whether to use or not David's infrastructure is something that you will have to decide on a project-by-project basis.
Toni

Miles,
I like your idea but I also like David's. What I would like to see in the end is *one* big place for community driven Scala projects, not two of them.
I am not picky about the license agreement, already signed both of them. And the tooling sets are almost identical. Thus both initiatives look very promising and whichever will make the race, I will support.
Cheers,
Heiko
2009/9/13 Miles Sabin <miles@milessabin.com>

If we go down this route then my company would be willing to fund at
least the first year of operation (although obviously other
contributors would be very welcome).

To go ahead I'd like a thumbs up from Martin, and Alex, Heiko, Erik,
Paul and Josh (as likely leaders of the modularization, I/O and build
infrastructure working groups). I'd also like to have David's buy in.

Concretely I propose we,

* host code on github.
* use github's issue tracker.
* use a service like RunCodeRun[1] for builds.
* use google groups for discussion.

Subject to a signed Scala Contributor License Agreement[2] commit and
posting rights would be given to,

* anyone actively involved in a Scala standard library working group.
* any current committer to the main EPFL tree.

All code would have to be published under the Scala License[3]. No
other strings attached.

I suggest we try this out for practicality using the free account
options of the various services and then upgrade to an appropriate
paid plan if it looks like it's going to work out in practice.

Let me know what you think ...

[1] http://runcoderun.com/
[2] http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf
[3] http://www.scala-lang.org/node/146

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

On Sun, Sep 13, 2009 at 1:58 AM, Paul Phillips wrote:
> On Sun, Sep 13, 2009 at 12:49:37AM +0100, Kevin Wright wrote:
>> I'm not 100% convinced that RunCodeRun can provide the goods for this,
>> especially given the fragile versioning issues that Scala has.
>
> Not sure if anyone knows I got scala going on runcoderun a while ago.
> It took a few go-arounds with them to get the tools in place so scalac
> would compile, but eventually I had it building successfully.
>
>  http://runcoderun.com/paulp/scala

I didn't at the outset, but I did notice a paulp/scala build going
past on the front page at one point when I was checking out the
pricing, and that encouraged me in thinking that this would be
workable.

> However I never got around to setting up the running of the tests.  All
> in all I would say that while they were helpful in making the changes
> necessary to get scalac building, I am skeptical that it would be very
> satisfying to depend on someone else's infrastructure for testing (the
> more so if we're open source freeloaders.)

Which is why I was assuming we'd need to go for one of the paid-for
options. If it turns out that RunCodeRun isn't ideal then we can look
at other options. Slicehost[1] maybe ... I'm open to suggestions.

> As a supplement to something else, I'm all for it, which indeed is why I
> started setting it up in the first place.
>
> Also, I haven't heard good things about github's issue tracker, but
> that's not a first-hand assessment.

Again, there are other options for issue tracking ... suggestions
welcome. Having the issue tracker closely associated with the source
repository seems likely to be a win however.

Cheers,

Miles

On Sun, Sep 13, 2009 at 2:08 AM, Erik Engbrecht
wrote:
> [1] If the community does decide to go with Lift, I'll make an effort to get
> the agreement reviewed by an IP attorney so that hopefully either I can be
> made to feel comfortable with it or I can feed competent feedback to DPP.

Unfortunately it was precisely this point ... the cost and general
hassle of consulting an IP lawyer with US legal expertise multiplied
by the number of potential contributors who would feel obliged to do
that (I would be one of them as well) ... that made me think that
other options would be preferable.

Cheers,

Miles

On Sun, Sep 13, 2009 at 12:11 PM, Antonio Cunei wrote:
> For the record I am currently looking into setting up a community-oriented
> companion to scala-lang, hosted at EPFL, in order to have a usable workspace
> for Scala-related projects that everyone can find and use.

That sounds like a fantastic long term solution :-)

Cheers,

Miles

On Sat, 2009-09-12 at 23:34 +0100, Miles Sabin wrote:
> To go ahead I'd like a thumbs up from Martin, and Alex, Heiko, Erik,
> Paul and Josh (as likely leaders of the modularization, I/O and build
> infrastructure working groups). I'd also like to have David's buy in.

I'm neither of those, but I like the idea in general. More comments
below.

> * host code on github.
> * use github's issue tracker.

As I said in another message, I'd be careful about using this option
(particularly if any of the contributors rely on email notifications).

> Subject to a signed Scala Contributor License Agreement[2] commit and
> posting rights would be given to,
>
> * anyone actively involved in a Scala standard library working group.
> * any current committer to the main EPFL tree.
>
> All code would have to be published under the Scala License[3]. No
> other strings attached.

I think this is very important. Contributing to incubator projects
should have the same terms (license and contributor agreement) as
contributing to Scala directly. As said elsewhere, if there are issues
with the existing approach used for Scala contributions, they should be
fixed.

> I suggest we try this out for practicality using the free account
> options of the various services and then upgrade to an appropriate
> paid plan if it looks like it's going to work out in practice.

Makes sense. I'd just add a "and if needed" at the end of the last
sentence in the previous paragraph.

Best,
Ismael

Hey Paul,

On Sat, 2009-09-12 at 17:58 -0700, Paul Phillips wrote:
> Also, I haven't heard good things about github's issue tracker, but
> that's not a first-hand assessment.

When we moved Voldemort from Google Code to github we really tried using
the github issue tracker. After a few weeks, we gave up and went back to
Google Code for the issue tracker.

At the time (not long ago), there was no way to assign a bug to
someone[1] or a way to add someone to the CC list. In other words, email
notifications were not appropriate (you'd only get them as a reporter)
and that is pretty crucial in my books.

Best,
Ismael

[1] The way people simulate this is to use labels for each contributor.
This doesn't solve the email notification issue though.

On Sun, Sep 13, 2009 at 6:13 PM, Ismael Juma wrote:
> On Sat, 2009-09-12 at 17:58 -0700, Paul Phillips wrote:
>> Also, I haven't heard good things about github's issue tracker, but
>> that's not a first-hand assessment.
>
> When we moved Voldemort from Google Code to github we really tried using
> the github issue tracker. After a few weeks, we gave up and went back to
> Google Code for the issue tracker.
>
> At the time (not long ago), there was no way to assign a bug to
> someone[1] or a way to add someone to the CC list. In other words, email
> notifications were not appropriate (you'd only get them as a reporter)
> and that is pretty crucial in my books.

Colin Howe just mailed me to suggest we look at Lighthouse,

http://lighthouseapp.com/

Free for use with open source projects and it appears to have github
integration.

Cheers,

Miles

I am totally cool with this.  Less work for me is a good amount of work. ;-)
In terms of scala-tools.org, we can have Hudson pull any open source project and build/publish it (as long as it has reasonably clean IP, but it sounds like that hurdle will be clear in this case.)  We can create a Nexus account for the project so release versions could be pushed to the release repository.
Working the IP issues however you see best is great.  Having everyone sign an EPFL CLA seems on its face as the best idea (this is not legal advice.)  More broadly, there are a bunch of different organizations that do open source (e.g., Apache).  Using their legal agreements, etc. strikes me as a reasonable approach... the key hurdle is to get EPFL to accept the IP, so whatever they say is the way you have to go (and I'm betting EPFL has a lawyer that will give direction on this.)

On Sat, Sep 12, 2009 at 3:34 PM, Miles Sabin <miles@milessabin.com> wrote:

If we go down this route then my company would be willing to fund at
least the first year of operation (although obviously other
contributors would be very welcome).

To go ahead I'd like a thumbs up from Martin, and Alex, Heiko, Erik,
Paul and Josh (as likely leaders of the modularization, I/O and build
infrastructure working groups). I'd also like to have David's buy in.

Concretely I propose we,

* host code on github.
* use github's issue tracker.
* use a service like RunCodeRun[1] for builds.
* use google groups for discussion.

Subject to a signed Scala Contributor License Agreement[2] commit and
posting rights would be given to,

* anyone actively involved in a Scala standard library working group.
* any current committer to the main EPFL tree.

All code would have to be published under the Scala License[3]. No
other strings attached.

I suggest we try this out for practicality using the free account
options of the various services and then upgrade to an appropriate
paid plan if it looks like it's going to work out in practice.

Let me know what you think ...

[1] http://runcoderun.com/
[2] http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf
[3] http://www.scala-lang.org/node/146

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On Sun, Sep 13, 2009 at 7:16 PM, Miles Sabin <miles@milessabin.com> wrote:

On Sun, Sep 13, 2009 at 6:13 PM, Ismael Juma <mlists@juma.me.uk> wrote:
> On Sat, 2009-09-12 at 17:58 -0700, Paul Phillips wrote:
>> Also, I haven't heard good things about github's issue tracker, but
>> that's not a first-hand assessment.
>
> When we moved Voldemort from Google Code to github we really tried using
> the github issue tracker. After a few weeks, we gave up and went back to
> Google Code for the issue tracker.
>
> At the time (not long ago), there was no way to assign a bug to
> someone[1] or a way to add someone to the CC list. In other words, email
> notifications were not appropriate (you'd only get them as a reporter)
> and that is pretty crucial in my books.

Colin Howe just mailed me to suggest we look at Lighthouse,

 http://lighthouseapp.com/

Free for use with open source projects and it appears to have github
integration.

Cheers,


Miles

If we're going the route of a commercial provider who's friendly to open source, then I definitely think that Jira should also be put up for consideration.
 

On 12 Sep 2009, at 23:34, Miles Sabin wrote:

> To go ahead I'd like a thumbs up from Martin, and Alex, Heiko, Erik,
> Paul and Josh (as likely leaders of the modularization, I/O and build
> infrastructure working groups). I'd also like to have David's buy in.

I'm not sure I'm important, just opinionated :-) But you can have my
opinions ...

> Concretely I propose we,
>
> * host code on github.
> * use github's issue tracker.
> * use a service like RunCodeRun[1] for builds.
> * use google groups for discussion.
>
> Subject to a signed Scala Contributor License Agreement[2] commit and
> posting rights would be given to,
>
> * anyone actively involved in a Scala standard library working group.
> * any current committer to the main EPFL tree.
>
> All code would have to be published under the Scala License[3]. No
> other strings attached.

I like the idea of hosting on github. Perhaps we could have a github/
scala-incubator alias which we could all sync to instead of any one
person's login details? Ultimately the account could be handled by the
EPFL.

The google groups also makes it easy for others to join in the
conversation (as well as see and search the public archives).

I have no experience of RCR so couldn't comment on that. Nor have I
used GitHub's issue tracker. I would say that having an issue tracker
that has a Mylyn capable connector would be very beneficial (but not
necessarily essential). Since it has already been mentioned on this
thread, I'd put a personal recommendation in for JIRA who host free
accounts for open source projects, which has the nice advantage of a
relatively good web-based UI as well as a Mylyn connector in Eclipse
(and bear in mind that Eclipse is also the IDE used for Scala work as
well ...)

I think the SCLA is a good pre-requisite for the membership of the
tree. Perhaps there ought to be a consensus voting system to allow
others to join? I think it's a no-brainer to let the EPFL committers
have access but I'm not sure that others (inc. myself) should
necessarily automatically have commit rights without a vote. Some
people might not like my indentation style, for example :-) In any
case, making it a vote based system would be a more transparent way of
getting commit rights.

Re 'posting rights' - is this for the google group? It might be better
to have it open wider (or even allow anyone to post). That would
result in some posting questions in a user capacity but who have no
interest in committing.

Alex

On Sat, Sep 12, 2009 at 11:34 PM, Miles Sabin wrote:
> Let me know what you think ...

(Sorry about the lag on this ... I've been tied up with the JVM
Languages Summit and suchlike ...).

OK, it seems like this got a general thumbs up.

So, next steps? Do we have a consensus on which services we want to use?

Cheers,

Miles

On 24 Sep 2009, at 13:37, Miles Sabin wrote:

> OK, it seems like this got a general thumbs up.
>
> So, next steps? Do we have a consensus on which services we want to
> use?

I think GitHub is probably the way forward for a source repository.
Someone created http://github.com/scala/ in the past; anyone know
about it? Doesn't seem to have moved much since its creation in Feb 09
though.

I also think that it should be possible to get a hosted JIRA account
for issue tracker items. However, something else that has Mylyn
integration probably works too.

Once we have an issue tracker and a codebase to fork from, I think
other services (build/test etc.) can come on-line later.

Alex

On 25 Sep 2009, at 09:42, Alex Blewitt wrote:

On 24 Sep 2009, at 13:37, Miles Sabin wrote:

OK, it seems like this got a general thumbs up.

So, next steps? Do we have a consensus on which services we want to use?

I think GitHub is probably the way forward for a source repository. Someone created http://github.com/scala/ in the past; anyone know about it? Doesn't seem to have moved much since its creation in Feb 09 though.

A couple of further points:
An earlier mail suggested that Paul's GitHub was a de-facto upstream copy of Scala:
"I would say mine is the de facto git mirror of trunk, so to the extent
there's some advantage to having that in one place (and I don't know
what that advantage is) it may as well be me.  Mine also has a few handy
branches available, like 2.7.x.http://github.com/paulp/scala/tree/master"

Given that this is supposed to be an incubator, does it make sense for there to be an incubator branch of an upstream clone of Scala? That would facilitate upstream pushing. In addition, it probably makes sense to use the scala.* prefix instead of scalax.* because that just causes massive amounts of pain when it comes to renaming (or otherwise) in the codebase. Lastly, given that we hope to move Scala to a more modular system anyway, it really shouldn't matter where modules come from.
Alex