2.7.7 candidate

Is it in the Scala-tools.org snapshots repository?

On Wed, Sep 23, 2009 at 8:30 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

David, Jorge,

A candidate for the 2.7.7 release is now available in the nightly download area: http://www.scala-lang.org/node/212/distributions. It is identical to 2.7.6 (and 2.7.5) except for a more proper fix of the "malformed Scala signature" message.

Please try this build out with Lift at your convenience. If all works fine we can either release it as 2.7.7, or publish it as a (still identical) RC. This last step, however, might be unnecessary. To put things in perspective, the 2.7.6 release has been out for two weeks now and, despite the incorrect fix, we received no additional reports of problems related to that.

In any event, as a preliminary step it would be good if you could please try out this initial version.

Thanks!
Toni

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

I checked and it isn't, for some reason it was not pushed there by the
nightly build script (it has not been in use for several months, and things
may have moved around in the meantime). We should be able to do that
though, if the .tgz is not adequate for the test. I'll look into it.
Toni

David Pollak wrote:
> Is it in the Scala-tools.org snapshots repository?
>
> On Wed, Sep 23, 2009 at 8:30 AM, Antonio Cunei wrote:
>
>> David, Jorge,
>>
>> A candidate for the 2.7.7 release is now available in the nightly download
>> area: http://www.scala-lang.org/node/212/distributions. It is identical to
>> 2.7.6 (and 2.7.5) except for a more proper fix of the "malformed Scala
>> signature" message.
>>
>> Please try this build out with Lift at your convenience. If all works fine
>> we can either release it as 2.7.7, or publish it as a (still identical) RC.
>> This last step, however, might be unnecessary. To put things in perspective,
>> the 2.7.6 release has been out for two weeks now and, despite the incorrect
>> fix, we received no additional reports of problems related to that.
>>
>> In any event, as a preliminary step it would be good if you could please
>> try out this initial version.
>>
>> Thanks!
>> Toni
>>
>
>
>

The script tries to upload to the snapshot repository into
org/scala-lang/scala-component/2.7.7-SNAPSHOT, and trying to create those
directories fails with "401 Unauthorized". I will contact the scala-tools
admins to have it sorted out.
Toni

Antonio Cunei wrote:
> I checked and it isn't, for some reason it was not pushed there by the
> nightly build script (it has not been in use for several months, and
> things may have moved around in the meantime). We should be able to do
> that though, if the .tgz is not adequate for the test. I'll look into it.
> Toni
>
> David Pollak wrote:
>> Is it in the Scala-tools.org snapshots repository?
>>
>> On Wed, Sep 23, 2009 at 8:30 AM, Antonio Cunei
>> wrote:
>>
>>> David, Jorge,
>>>
>>> A candidate for the 2.7.7 release is now available in the nightly
>>> download
>>> area: http://www.scala-lang.org/node/212/distributions. It is
>>> identical to
>>> 2.7.6 (and 2.7.5) except for a more proper fix of the "malformed Scala
>>> signature" message.
>>>
>>> Please try this build out with Lift at your convenience. If all works
>>> fine
>>> we can either release it as 2.7.7, or publish it as a (still
>>> identical) RC.
>>> This last step, however, might be unnecessary. To put things in
>>> perspective,
>>> the 2.7.6 release has been out for two weeks now and, despite the
>>> incorrect
>>> fix, we received no additional reports of problems related to that.
>>>
>>> In any event, as a preliminary step it would be good if you could please
>>> try out this initial version.
>>>
>>> Thanks!
>>> Toni
>>>
>>
>>
>>
>
>

Josh,
Any thoughts on why Antonio is getting a 401?
Thanks,
David

On Wed, Sep 23, 2009 at 9:33 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

The script tries to upload to the snapshot repository into org/scala-lang/scala-component/2.7.7-SNAPSHOT, and trying to create those directories fails with "401 Unauthorized". I will contact the scala-tools admins to have it sorted out.
Toni

Antonio Cunei wrote:

I checked and it isn't, for some reason it was not pushed there by the nightly build script (it has not been in use for several months, and things may have moved around in the meantime). We should be able to do that though, if the .tgz is not adequate for the test. I'll look into it.
Toni

David Pollak wrote:

Is it in the Scala-tools.org snapshots repository?

On Wed, Sep 23, 2009 at 8:30 AM, Antonio Cunei <antonio.cunei@epfl.ch>wrote:

David, Jorge,

A candidate for the 2.7.7 release is now available in the nightly download
area: http://www.scala-lang.org/node/212/distributions. It is identical to
2.7.6 (and 2.7.5) except for a more proper fix of the "malformed Scala
signature" message.

Please try this build out with Lift at your convenience. If all works fine
we can either release it as 2.7.7, or publish it as a (still identical) RC.
This last step, however, might be unnecessary. To put things in perspective,
the 2.7.6 release has been out for two weeks now and, despite the incorrect
fix, we received no additional reports of problems related to that.

In any event, as a preliminary step it would be good if you could please
try out this initial version.

Thanks!
Toni

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

Antonio,
Not to put too fine a point on it, but improving the release process around Scala is hyper-critical as more companies rely on Scala for their business.  Future mis-steps in release (e.g., releasing software without testing, re-releasing versions with different bits, etc.) may tarnish Scala's well deserved reputation for being an excellent balance between academic research and a practical, usable language.
If a Scala pre-release is not on scala-tools.org (or in the main Maven repository), then it isn't "available".  If it's not available, it can't be tested.  If it can't be tested, then it can't be released.  The admins on scala-tools.org are available to help you with any issues related to publishing the bits.  In fact, if you want to set up Hudson processes to build Scala nightlies, that'd be great.  Hudson on scala-tools.org would build from the repo and publish snapshots as soon as the repo code changed.
Let's all work together to bring the Scala coding and release processes up to the caliber of Scala the language.
Thanks,
David

On Wed, Sep 23, 2009 at 9:11 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

I checked and it isn't, for some reason it was not pushed there by the nightly build script (it has not been in use for several months, and things may have moved around in the meantime). We should be able to do that though, if the .tgz is not adequate for the test. I'll look into it.
Toni

David Pollak wrote:

Is it in the Scala-tools.org snapshots repository?

On Wed, Sep 23, 2009 at 8:30 AM, Antonio Cunei <antonio.cunei@epfl.ch>wrote:

David, Jorge,

A candidate for the 2.7.7 release is now available in the nightly download
area: http://www.scala-lang.org/node/212/distributions. It is identical to
2.7.6 (and 2.7.5) except for a more proper fix of the "malformed Scala
signature" message.

Please try this build out with Lift at your convenience. If all works fine
we can either release it as 2.7.7, or publish it as a (still identical) RC.
This last step, however, might be unnecessary. To put things in perspective,
the 2.7.6 release has been out for two weeks now and, despite the incorrect
fix, we received no additional reports of problems related to that.

In any event, as a preliminary step it would be good if you could please
try out this initial version.

Thanks!
Toni

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

>>>>> "David" == David Pollak writes:

David> to help you with any issues related to publishing the bits. In
David> fact, if you want to set up Hudson processes to build Scala
David> nightlies, that'd be great. Hudson on scala-tools.org would
David> build from the repo and publish snapshots as soon as the repo
David> code changed.

Man, that would be terrific. To be able to easily point sbt (or maven
or ivy or what have you) at arbitrary Scala nightlies would make the
whole process of helping test 2.8 a great deal more pleasant.

On 23 Sep 2009, at 18:48, Seth Tisue wrote:

>>>>>> "David" == David Pollak writes:
>
> David> to help you with any issues related to publishing the bits. In
> David> fact, if you want to set up Hudson processes to build Scala
> David> nightlies, that'd be great. Hudson on scala-tools.org would
> David> build from the repo and publish snapshots as soon as the repo
> David> code changed.
>
> Man, that would be terrific. To be able to easily point sbt (or maven
> or ivy or what have you) at arbitrary Scala nightlies would make the
> whole process of helping test 2.8 a great deal more pleasant.

FWIW I think we should avoid putting release candidates onto the
central maven repository. They only have a limited lifetime, their
versions will be higher than their released/stable counterparts
(meaning that if someone takes down the bits, they might be compiling/
using that erroneously) and in any case, there may be bugs which could
leak to widely used repositories if not careful.

Given that it's fairly easy to host a maven repository structure
elsewhere, I'd recommend having separate mini-maven repositories for
nightlies and release candidates. The nightlies could be cleaned up
every n days (for some small value of n) and the release candidates
might have a lifetime up until the final, after which the next round
of release candidates could wait until the next revision is made.

Lastly, the version of the release candidate at the moment is
2.7.7.final, which suggests it's a final before it's a final. We
should avoid polluting the main maven repository namespace with that
kind of possibilitiy.

With that said, I'm all for the idea of having such maven repos
available.

http://maven.apache.org/guides/introduction/introduction-to-repositories...

Alex

David,

David Pollak wrote:
> If a Scala pre-release is not on scala-tools.org (or in the main Maven
> repository), then it isn't "available".

This is a very Maven-centric view. As great a tool Maven can possibly be,
you cannot really say that, if something is not in the Maven repository, it
does not exist.

In any event, we do our best to make the life of all the people who depend
on Maven easier, by pushing to scala-tools all of our builds. I believe
this is exactly what you are asking for, isn't it?

> If it can't be tested, then it can't be released.
> [...] In fact, if you want to set up Hudson processes to
> build Scala nightlies, that'd be great.

The Scala nightlies already are on scala-tools, from what I can tell. For
instance:

http://scala-tools.org/repo-snapshots/org/scala-lang/scala-compiler/2.8....

The 2.7.7 nightly was made available today, and we are now working together
to push it to the Maven repository. This seems to be exactly what you ask
for in terms of collaboration.

I must say that the tone of your message sounds more like a put-down than
anything else. I hope that was not the intention.

Alex Blewitt wrote:
> the version of the release candidate at the moment is 2.7.7.final, which suggests it's a final before it's a final. We should avoid polluting the main maven repository namespace with that kind of possibilitiy.

You will find that the version in the source files is not what ends up in
the nightly. That is overwritten and displayed as
"2.7.7.r18746-b20090923020104", or equivalent string, and the jars assume
similar names. It remains "2.7.7.final" only when built for a real release.
If you saw "2.7.7.final" in any of the nightly files, please let me know.
Toni

On Wed, Sep 23, 2009 at 2:20 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

David,

David Pollak wrote:

If a Scala pre-release is not on scala-tools.org (or in the main Maven
repository), then it isn't "available".

This is a very Maven-centric view. As great a tool Maven can possibly be, you cannot really say that, if something is not in the Maven repository, it does not exist.

In any event, we do our best to make the life of all the people who depend on Maven easier, by pushing to scala-tools all of our builds. I believe this is exactly what you are asking for, isn't it?

If it can't be tested, then it can't be released.
[...] In fact, if you want to set up Hudson processes to
build Scala nightlies, that'd be great.

The Scala nightlies already are on scala-tools, from what I can tell. For instance:

http://scala-tools.org/repo-snapshots/org/scala-lang/scala-compiler/2.8.0-SNAPSHOT

The 2.7.7 nightly was made available today, and we are now working together to push it to the Maven repository. This seems to be exactly what you ask for in terms of collaboration.

I must say that the tone of your message sounds more like a put-down than anything else. I hope that was not the intention.

My intention is to put under scrutiny the Scala release procedures, which by all objective measures are severely lacking.  If you disagree with this assessment, then I'm not sure we have enough common ground to have a further discussion about improving the situation.


 

Alex Blewitt wrote:

the version of the release candidate at the moment is 2.7.7.final, which suggests it's a final before it's a final. We should avoid polluting the main maven repository namespace with that kind of possibilitiy.

You will find that the version in the source files is not what ends up in the nightly. That is overwritten and displayed as "2.7.7.r18746-b20090923020104", or equivalent string, and the jars assume similar names. It remains "2.7.7.final" only when built for a real release.
If you saw "2.7.7.final" in any of the nightly files, please let me know.
Toni

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

>>>>> "Antonio" == Antonio Cunei writes:

David> If a Scala pre-release is not on scala-tools.org (or in the main Maven
David> repository), then it isn't "available".

Antonio> This is a very Maven-centric view. As great a tool Maven can
Antonio> possibly be, you cannot really say that, if something is not
Antonio> in the Maven repository, it does not exist.

Fair enough. But I'd like to point out that other tools pull stuff from
Maven repositories too, for example, sbt, which is emerging as the
standard build tool for Scala projects. (I hope never to use Maven
itself as long as I live, but I like sbt.)

Also, Lift is not just any Scala project.

Antonio> The Scala nightlies already are on scala-tools, from what I
Antonio> can tell. For instance:
Antonio> http://scala-tools.org/repo-snapshots/org/scala-lang/scala-compiler/2.8....

The reason this is far from completely satisfactory is that the
"SNAPSHOT" feature of Maven doesn't allow you to specify particular past
snapshots; you can only ask for the most recent one. So even though
previous nightlies are there, in that directory, in practice they're
inaccessible to a lot of people because they don't exist as uniquely
identified Maven artifacts.

This would be much less of a problem for people wanting to help test 2.8
if the Scala project would do occasional milestone releases, as
previously suggested by Josh Suereth:

http://article.gmane.org/gmane.comp.lang.scala.internals/964

The community doesn't necessarily need every nightly uniquely available
through Maven (though it would certainly be nice!). But the present
situation is that even though 2.8 has been in the works for quite a long
time now, no versions of Scala 2.8 are uniquely available through
these extremely convenient automated tools, and I think this is actually
a real problem inhibiting people from using 2.8 and getting their
projects working with it. People trying 2.8 and reporting issues is
something that should be happening now, I think, if the final 2.8
release is not to be needlessly delayed.

If it were just a litle easier for people to test the new stuff, I think
a lot of problems could get sorted out sooner rather than later.

See also Alex's recent post, which has some suggestions on how this
might work.

This stuff is on my mind right now because I've been struggling trying
to get my project, a Scala 2.8 snapshot, a ScalaTest 1.0 snapshot, and a
sbt 0.5.5 snapshot all working together, and the whole process has been
needlessly complicated by the fact that there aren't any shared, readily
identifiable and available 2.8 builds for all these projects to agree on
and use as a common reference point.

Hopefully this is a polite contribution to a thread that has gotten
rather tense. Cheers,

On Thu, September 24, 2009 12:50 am, Seth Tisue wrote:
> If it were just a litle easier for people to test the new stuff, I think
> a lot of problems could get sorted out sooner rather than later.
> [...]
> Hopefully this is a polite contribution to a thread that has gotten
> rather tense. Cheers,
>

Seth,

Thank you for your message and for your explanation. Politeness is always
welcome :)

Concerning setting up snapshots, I recall that when Josh sent that message
I replied stating that the various features that end up in trunk are
rarely synchronized in terms of development cycle. As a consequence, we
can rarely pinpoint snapshots that are "better" than others: trunk is
prone to continuous changes. Our fundamental metric to decide when a
snapshot is reasonably stable is that the test suite passes; at that stage
it is, at the best of our intentions, ready for further testing by the
user community. We then rely on that feedback to further improve our
testing suite, of course.

Pushing the resulting nightly files to the snapshot repo or to a
mini-repository is essentially the same for us; we entirely rely on the
community for Maven support (we do not have the internal resources to
follow that as well). How to organize the mini-repos is entirely up to the
scala-tools site, however. If you decide to implement such a solution,
please just let us have an updated deployment build file and we'll be
happy to update the nightly script to accommodate the change.

As for detecting when it might be worth creating more permanent
checkpoints for testing, the best source to gather that information is of
course the commit log:

http://lampsvn.epfl.ch/trac/scala/log/scala/trunk?limit=100&mode=stop_on...

It's all in the open: we don't hide that information. If you need to
publish certain snapshots at particular points in time, your best bet is
just checking the log in order to decide when that is most appropriate.
Again, if the testing suite does not pass there will be no nightly pushed
out, so all of the nightly builds that do become visible are good
candidates, as far as we can tell.

Thank you again for your message, I hope my reply can be of some help. f
you have further suggestions about this process however, or require
additional information, please just let me know.
Toni

Toni,

I'm thinking we should dual deploy the snapshot builds to the maven
repository so older nightlies can be found. I'll set this up and
commit a fix to the maven integration in the scala build.

Do you also need this in the 2.7.x branch?

Sent from my iPhone

On Sep 23, 2009, at 7:58 PM, "Antonio Cunei"
wrote:

> On Thu, September 24, 2009 12:50 am, Seth Tisue wrote:
>> If it were just a litle easier for people to test the new stuff, I
>> think
>> a lot of problems could get sorted out sooner rather than later.
>> [...]
>> Hopefully this is a polite contribution to a thread that has gotten
>> rather tense. Cheers,
>>
>
> Seth,
>
> Thank you for your message and for your explanation. Politeness is
> always
> welcome :)
>
> Concerning setting up snapshots, I recall that when Josh sent that
> message
> I replied stating that the various features that end up in trunk are
> rarely synchronized in terms of development cycle. As a consequence,
> we
> can rarely pinpoint snapshots that are "better" than others: trunk is
> prone to continuous changes. Our fundamental metric to decide when a
> snapshot is reasonably stable is that the test suite passes; at that
> stage
> it is, at the best of our intentions, ready for further testing by the
> user community. We then rely on that feedback to further improve our
> testing suite, of course.
>
> Pushing the resulting nightly files to the snapshot repo or to a
> mini-repository is essentially the same for us; we entirely rely on
> the
> community for Maven support (we do not have the internal resources to
> follow that as well). How to organize the mini-repos is entirely up
> to the
> scala-tools site, however. If you decide to implement such a solution,
> please just let us have an updated deployment build file and we'll be
> happy to update the nightly script to accommodate the change.
>
> As for detecting when it might be worth creating more permanent
> checkpoints for testing, the best source to gather that information
> is of
> course the commit log:
>
> http://lampsvn.epfl.ch/trac/scala/log/scala/trunk?limit=100&mode=stop_on...
>
> It's all in the open: we don't hide that information. If you need to
> publish certain snapshots at particular points in time, your best
> bet is
> just checking the log in order to decide when that is most
> appropriate.
> Again, if the testing suite does not pass there will be no nightly
> pushed
> out, so all of the nightly builds that do become visible are good
> candidates, as far as we can tell.
>
> Thank you again for your message, I hope my reply can be of some
> help. f
> you have further suggestions about this process however, or require
> additional information, please just let me know.
> Toni
>
>

On Thu, September 24, 2009 2:35 am, Josh Suereth wrote:
> Toni,
>
> I'm thinking we should dual deploy the snapshot builds to the maven
> repository so older nightlies can be found. I'll set this up and
> commit a fix to the maven integration in the scala build.
>

Thank you Josh!

> Do you also need this in the 2.7.x branch?
>

Probably not. If the current 2.7.7-SNAPSHOT is usable for the initial
testing, backporting won't be necessary. We might have one additional
nightly with a couple of Eclipse-only plugin fixes that Miles would like
to commit, and subsequently an RC, but hopefully we won't need to keep
multiple nightly builds around for 2.7.x.

Thanks!
Toni

Antonio Cunei wrote:
> David, Jorge,
>
> A candidate for the 2.7.7 release is now available in the nightly
> download area: http://www.scala-lang.org/node/212/distributions. It is
> identical to 2.7.6 (and 2.7.5) except for a more proper fix of the
> "malformed Scala signature" message.

Please, please include this patch
https://lampsvn.epfl.ch/trac/scala/ticket/1473

There are some tools with -Ydebug hardcoded, and it's not possible to
use them w/o applying this patch manually to the compiler.

On Thu, Sep 24, 2009 at 10:33 PM, Vladimir Kirichenko
wrote:
> There are some tools with -Ydebug hardcoded, and it's not possible to
> use them w/o applying this patch manually to the compiler.

Which tools are those?

Cheers,

Miles

On Wed, Sep 23, 2009 at 4:58 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

On Thu, September 24, 2009 12:50 am, Seth Tisue wrote:
> If it were just a litle easier for people to test the new stuff, I think
> a lot of problems could get sorted out sooner rather than later.
> [...]
> Hopefully this is a polite contribution to a thread that has gotten
> rather tense.  Cheers,
>

Seth,

Thank you for your message and for your explanation. Politeness is always
welcome :)

I look forward to a new era where EPFL has a policy of politeness to people in the community.  I will certainly reciprocate.

However, branding my requirements as "Maven centric" is not polite.  Releasing 2.7.6 without any discussion with the community and not apologizing for the quality of the release are not polite.

Dismissing every one of my ticket submissions over the last year with a wave of a hand and a "I've looked at my code and it looks fine to me," is not polite.

I am direct and confrontational because this is the only strategy that I have seen to be effective with EPFL.  I would certainly like to have a more polite and respectful environment, as we do on the Lift list.
 

Concerning setting up snapshots, I recall that when Josh sent that message
I replied stating that the various features that end up in trunk are
rarely synchronized in terms of development cycle. As a consequence, we
can rarely pinpoint snapshots that are "better" than others: trunk is
prone to continuous changes.

This strikes me as a failure of process.  I understand that Scala is complex and that there is a lot of coordination between contributors.  However, rolling a feature into trunk, letting the feature settle, releasing a milestone, and getting feedback on the milestone, and repeating the process for the material changes to Scala would (1) be a way to test each new feature and (2) be a significantly better way to get feedback from Scala users because the feedback would generally be isolated to a single "big change".

Scala is being advertised by EPFL as ready for enterprise use.  In order to come close to meeting that billing, there must be a process in place for integrating significant changes.  "Test whatever's around on a give day" is not such a process.
 

Our fundamental metric to decide when a
snapshot is reasonably stable is that the test suite passes; at that stage
it is, at the best of our intentions, ready for further testing by the
user community. We then rely on that feedback to further improve our
testing suite, of course.

Part of the test suite should include building the popular Scala projects including Lift, ScalaZ, Configgy, SBT, ScalaTest, ScalaCheck, Specs etc.  If those packages build and pass their own internal tests, you have a good amount of coverage in terms of the way Scala is being used in the wild.

Please don't respond with "we don't have the time/resources."  Please see my above assertion about the way that Scala is being advertised by EPFL.  Further, every resource allocation decision has impacts.  If EPFL decides not to invest the 2-man weeks that it would take to set up a test harness that would build the above projects, there are two other options: (1) community does it or (2) nobody does it.  If it's the former, EPFL is asking the community to invest $10K-$20K of someone's time to do the work.  If it's the latter, EPFL will continue to have release disasters (what's the polite way to describe the 2.7.6 release?)
 

Pushing the resulting nightly files to the snapshot repo or to a
mini-repository is essentially the same for us; we entirely rely on the
community for Maven support (we do not have the internal resources to
follow that as well). How to organize the mini-repos is entirely up to the
scala-tools site, however. If you decide to implement such a solution,
please just let us have an updated deployment build file and we'll be
happy to update the nightly script to accommodate the change.

As for detecting when it might be worth creating more permanent
checkpoints for testing, the best source to gather that information is of
course the commit log:

http://lampsvn.epfl.ch/trac/scala/log/scala/trunk?limit=100&mode=stop_on_copy&format=rss

It's all in the open: we don't hide that information.

I will be happy to respond in kind.  If it's the policy that any information that one needs can be found in commit notes, then it will be the Lift policy that anything that EPFL wants from Lift can be found in the Lift repository.  That doesn't feel too good, does it?  It doesn't give you the sense that we're working with you.  It certainly doesn't seem polite.

EPFL has weekly meetings on Tuesdays.  I'm sure there could be an agenda item, "is the current snapshot a milestone candidate?" at every meeting.  It's a simple decision.  If the decision is "yes" then either create a tag and send a note to internals.
 

If you need to
publish certain snapshots at particular points in time, your best bet is
just checking the log in order to decide when that is most appropriate.

The problem becomes, "what is an authoritative Scala milestone/release?"  If EPFL wants to cede making those decisions to the community, that is huge change in the existing process where EPFL marks release candidates and final versions.  If Martin states to the community, "EPFL is no longer going to mark milestones, release candidates, or final versions," then the community will have to mobilize to figure out how to make those determinations.  But until that statement is made, I expect EPFL to be the authority on milestones and releases.

I have already offered to host Scala on the scala-tools.org CI server.  I reiterate that offer.  This will reduce the burden on EPFL to publish builds.  Further, if it is so burdensome to create milestone builds and publish them to scala-tools.org (which replicates to the main Maven repositories), I'm sure we can arrange to have someone in the community pull tagged code from EPFL's SVN repository and do builds.

So, even in this politely worded note, you've told the community that EPFL doesn't really care about the communities needs, which in my opinion is not a polite message.

David

Again, if the testing suite does not pass there will be no nightly pushed
out, so all of the nightly builds that do become visible are good
candidates, as far as we can tell.

Thank you again for your message, I hope my reply can be of some help. f
you have further suggestions about this process however, or require
additional information, please just let me know.
Toni

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

If we're going to open up the patches, let's fix the massively broken structural types (they are not thread safe), the use of the FJ Library in Actors which causes out of memory problems after a bunch of messages have been sent to Actors and non-thread-safe object creation.  These are all ticking timebombs.

On Thu, Sep 24, 2009 at 2:33 PM, Vladimir Kirichenko <vladimir.kirichenko@gmail.com> wrote:

Antonio Cunei wrote:
> David, Jorge,
>
> A candidate for the 2.7.7 release is now available in the nightly
> download area: http://www.scala-lang.org/node/212/distributions. It is
> identical to 2.7.6 (and 2.7.5) except for a more proper fix of the
> "malformed Scala signature" message.

Please, please include this patch
https://lampsvn.epfl.ch/trac/scala/ticket/1473

There are some tools with -Ydebug hardcoded, and it's not possible to
use them w/o applying this patch manually to the compiler.

--
Best Regards,
Vladimir Kirichenko

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

Miles Sabin wrote:
> On Thu, Sep 24, 2009 at 10:33 PM, Vladimir Kirichenko
> wrote:
>> There are some tools with -Ydebug hardcoded, and it's not possible to
>> use them w/o applying this patch manually to the compiler.
> Which tools are those?

IDEA plugin for 8 as example.

I've been sitting on a response to this thread for a while. I don't mean to beat a dead horse or to reopen old wounds, but I think the underlying issues here are still unresolved and should be addressed.

There's a Bjarne Stroustrup quote that's been floating around Twitter for a couple of days: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." I think it's a testament to Scala's great usefulness and even greater potential that people can get so worked up about even very little things. Even though I might complain, I think it's important not to lose sight of all the work that has gone into Scala. I'm sure I'm not alone in appreciating all the hard work that Martin and the entire team at EPFL have put into Scala. You've made a truly compelling programming language; so compelling that it's getting popular.

Toni, in particular, has done a great job engaging with the community, keeping the website up-to-date, posting new polls and blog posts, gardening Trac, baby-sitting the build and release process, etc. When scala-blogs.org was started almost two years ago, there was very little blogging about Scala. It's incredibly satisfying to see that the official scala-lang.org now posts more blog content than scala-blogs.org, and that there's a burgeoning interest in Scala among the wider blogosphere. I also really appreciate, Toni, your work (above and beyond the call of duty) to backport a patch for a critical bug to the 2.7.x branch. It's comforting to know that branch hasn't been completely abandoned, as some people may be stuck on it long after 2.8.0 has been released.

That said, sometimes I feel that EPFL is out of touch with the needs of Scala's users. I imagine there's a vanishingly small number of non-trivial Scala projects (other than the compiler itself) that don't depend on one of Scalacheck, ScalaTest, or Specs. Real projects require real testing, and most Scala projects use one or more of these testing libraries for their tests. Taking as a given that Scala releases are binary incompatible, a release of Scala that is not known to work with these three libraries is, for all practical purposes, also not known to be generally useful. It is also important that a release of Scala work with some other popular projects which, because of their nature as libraries, frameworks, or tools, have a lot of code which depends on them. Projects in this last category that come to mind: Lift, SBT, Configgy, Akka, Scalax, Scalaz, and probably more that I'm forgetting. If these critical projects don't work with a given Scala release, then many more projects which depend on them won't be able to work with that Scala release either. If users can't trust that their libraries will work with future Scala releases, adding library dependencies to a project becomes a real liability.

For another example, take my employer, LinkedIn. Our infrastructure is organized around a service-oriented architecture. A single service, when pushed to production, might be running on dozens of machines and handling millions of requests per day. Our services are expected to run for weeks and months without interruption. In such a scenario, even small memory leaks are completely unacceptable, and the only uncertainty with respect to subtle concurrency bugs is when (not if) they will rear their ugly heads. Given this, it's extremely alarming to find that precisely such bugs (Ticket #1006), -in the core of the language-, have been known about for over a year and have first been ignored and later disputed. It's bad enough when bugs are in the standard library, but at least those can be worked around (more on this later). But when the bugs are in the core language, there's very little a user can do to avoid them.

LinkedIn is also stuck using Java 1.5. Our engineers overwhelmingly use Macs for development, and bugs in Apple's 1.6 JDK prevent us from upgrading to 1.6. I'm sure LinkedIn is not the only company that unfortunately needs to stay on 1.5 way past it's expiration date. We only have a few hundred engineers; it should be relatively trivial (compared to other, much larger, software shops) for us to migrate to 1.6, but we can't. Which leads us to bug #2380. Given how implicits work, Scala can't claim to support Java 1.5 unless it's compiled against Java 1.5. Frankly, this bug terrifies me. I have no idea where or how it might strike, and it will lurk in utmost silence until it's ready to kill.

Now, I've been using Scala long enough that I know where the major potholes in the standard libraries are, and I've tried to communicate them to my coworkers. Don't use Source, it won't actually close the file. Don't use immutable.Map, it's not actually immutable. Avoid collection.jcl, it's totally broken. From a purely self-centered perspective, it might actually be good for me that Scala is so buggy. I know where some of the bugs are, and that knowledge makes me valuable to people who aren't as familiar with Scala's deficiencies. But the truth is I don't want to be valuable for knowing how badly Scala is broken. I'd much rather be valuable for being able to show other people how awesome Scala is. Everyone expects a new technology to have some warts. That's understandable and forgivable. What's inexcusable is when fixes are handed to EPFL, sometimes on a silver platter, and either ignored or rejected. David MacIver contributed the actually-immutable IntMap and TreeHashMap over a year ago, yet immutable.Map still makes "immutable"-but-really-mutable-and-synchronized HashMaps. Daniel Spiewak was less lucky. He contributed his immutable persistent Vector 11 months ago, but lacking commit rights, his excellent work has languished in ticket #1509 that entire time. And it's probably best if we all just forgot about the time someone tried to fix Source.

Now, it's bad enough when the standard libraries are broken. That's annoying, but ultimately avoidable. But what happens when core language features are broken? My advice to other Scala users rings increasingly hollow. What am I supposed to say? Don't expect @volatile to work (#2424)? Don't use "finally" (#2392)?

Finally, that brings us to the topic of the 2.7.6 release. I, and surely others, had come to expect RC releases before a final release. Even in the best of times the process wasn't perfect, but it was better than nothing. (For much of 2.7.x I was responsible for porting Lift to new versions of Scala. After an RC came out, it was a race against the clock to try to compile Lift, because EPFL rushed towards -final and Lift can't compile until Specs and Scalacheck do.) What happened to the process? More importantly, how is it going to be prevented from happening again? Who needs to approve a release before it goes out? It's been stated that EPFL isn't secretive: Svn and Trac are out in the open. This may be true, but EPFL is hardly transparent. Even PaulP, -the author of the patch-, wasn't aware that it was being released. And he's more plugged in than most. He has insight into the scala-devel list, which--if not secretive--is certainly opaque.

I truly despise being the person to push for -more- process, but unfortunately processes exist for good reasons. A Scala release is for all practical purposes useless if it doesn't work with the three major testing frameworks. Furthermore, a Scala release is significantly crippled if it doesn't work with the more popular of the Scala-based libraries, frameworks, and tools listed above. At the very least, a plurality of these projects should be confirmed to compile and pass tests with a new Scala version before it can be considered final. LinkedIn has, by necessity, a very conservative process for vetting external libraries and releasing code. It would be unreasonable to expect a Scala release to wait until LinkedIn had compiled and tested all it's code against a release candidate before making a release final, but knowing that a particular Scala version compiled many disparate open source projects would give me substantial peace of mind to know that release was probably ok.

Now, the issue of transparency (really, opacity) runs deeper than just notifying the community of an imminent release. EPFL has a long-standing policy of not committing releases (particularly 2.8) to any fixed schedule, under the philosophy that it'll be ready when it's ready. I've been a strong (and sometimes vocal) supporter of this policy. I know these things take time and feel strongly that they shouldn't be rushed. That said, there's been absolutely no transparency on the part of EPFL surrounding the 2.8 release. In particular, what conditions need to be met before 2.8 is released? Which tickets are blockers? Which tickets can we expect to see fixed (that aren't already fixed in trunk)? If tickets are too specific, what general steps need to happen before a 2.8 release?

Transparency also applies to contributions. There's no policy on what non-breaking contributions will be accepted into the standard library. Nor a policy on what breaking changes are acceptable for minor or major releases. It's all, I'm afraid, quite arbitrary. IntMap goes in because David MacIver can commit it himself and no one feels strongly enough to object. Vector doesn't go in because Daniel Spiewak can't commit it himself and no one feels strongly enough to include it. Collection.jcl disappears without a trace or even a period of deprecation because no one can be bothered to reimplement it for 2.8 collections, but Source lives on for years and years in this zombie undead state because we can't tolerate a breaking change. (I certainly don't want to be interpreted as arguing for jcl's return. As far as I'm concerned, good riddance.) Even PaulP--who's more plugged in than most, has visibility into the opaque scala-devel, and has rights to commit his code--even PaulP frequently expresses uncertainty about whether his contributions will be simply ignored or rejected outright.

People at EPFL frequently state they lack the bandwidth to handle more Trac tickets, more process, slower releases, bugfix backports for Scala 2.7.x, support for Java 1.5, fixes for broken libraries, vetting user contributed code, etc. Unfortunately, all these things are essential if Scala is going to be credible for real, production use. How can these conflicting needs can be worked out?

I don't want to end on a bad note. Scala is a ground-breaking language and I appreciate all the effort that EPFL has put into it. But from where I'm standing, things can't continue they way they've been, so something has to change.

--j

On Thu, Sep 24, 2009 at 3:36 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Wed, Sep 23, 2009 at 4:58 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

On Thu, September 24, 2009 12:50 am, Seth Tisue wrote:
> If it were just a litle easier for people to test the new stuff, I think
> a lot of problems could get sorted out sooner rather than later.
> [...]
> Hopefully this is a polite contribution to a thread that has gotten
> rather tense.  Cheers,
>

Seth,

Thank you for your message and for your explanation. Politeness is always
welcome :)

I look forward to a new era where EPFL has a policy of politeness to people in the community.  I will certainly reciprocate.

However, branding my requirements as "Maven centric" is not polite.  Releasing 2.7.6 without any discussion with the community and not apologizing for the quality of the release are not polite.

Dismissing every one of my ticket submissions over the last year with a wave of a hand and a "I've looked at my code and it looks fine to me," is not polite.

I am direct and confrontational because this is the only strategy that I have seen to be effective with EPFL.  I would certainly like to have a more polite and respectful environment, as we do on the Lift list.
 

Concerning setting up snapshots, I recall that when Josh sent that message
I replied stating that the various features that end up in trunk are
rarely synchronized in terms of development cycle. As a consequence, we
can rarely pinpoint snapshots that are "better" than others: trunk is
prone to continuous changes.

This strikes me as a failure of process.  I understand that Scala is complex and that there is a lot of coordination between contributors.  However, rolling a feature into trunk, letting the feature settle, releasing a milestone, and getting feedback on the milestone, and repeating the process for the material changes to Scala would (1) be a way to test each new feature and (2) be a significantly better way to get feedback from Scala users because the feedback would generally be isolated to a single "big change".

Scala is being advertised by EPFL as ready for enterprise use.  In order to come close to meeting that billing, there must be a process in place for integrating significant changes.  "Test whatever's around on a give day" is not such a process.
 

Our fundamental metric to decide when a
snapshot is reasonably stable is that the test suite passes; at that stage
it is, at the best of our intentions, ready for further testing by the
user community. We then rely on that feedback to further improve our
testing suite, of course.

Part of the test suite should include building the popular Scala projects including Lift, ScalaZ, Configgy, SBT, ScalaTest, ScalaCheck, Specs etc.  If those packages build and pass their own internal tests, you have a good amount of coverage in terms of the way Scala is being used in the wild.

Please don't respond with "we don't have the time/resources."  Please see my above assertion about the way that Scala is being advertised by EPFL.  Further, every resource allocation decision has impacts.  If EPFL decides not to invest the 2-man weeks that it would take to set up a test harness that would build the above projects, there are two other options: (1) community does it or (2) nobody does it.  If it's the former, EPFL is asking the community to invest $10K-$20K of someone's time to do the work.  If it's the latter, EPFL will continue to have release disasters (what's the polite way to describe the 2.7.6 release?)
 

Pushing the resulting nightly files to the snapshot repo or to a
mini-repository is essentially the same for us; we entirely rely on the
community for Maven support (we do not have the internal resources to
follow that as well). How to organize the mini-repos is entirely up to the
scala-tools site, however. If you decide to implement such a solution,
please just let us have an updated deployment build file and we'll be
happy to update the nightly script to accommodate the change.

As for detecting when it might be worth creating more permanent
checkpoints for testing, the best source to gather that information is of
course the commit log:

http://lampsvn.epfl.ch/trac/scala/log/scala/trunk?limit=100&mode=stop_on_copy&format=rss

It's all in the open: we don't hide that information.

I will be happy to respond in kind.  If it's the policy that any information that one needs can be found in commit notes, then it will be the Lift policy that anything that EPFL wants from Lift can be found in the Lift repository.  That doesn't feel too good, does it?  It doesn't give you the sense that we're working with you.  It certainly doesn't seem polite.

EPFL has weekly meetings on Tuesdays.  I'm sure there could be an agenda item, "is the current snapshot a milestone candidate?" at every meeting.  It's a simple decision.  If the decision is "yes" then either create a tag and send a note to internals.
 

If you need to
publish certain snapshots at particular points in time, your best bet is
just checking the log in order to decide when that is most appropriate.

The problem becomes, "what is an authoritative Scala milestone/release?"  If EPFL wants to cede making those decisions to the community, that is huge change in the existing process where EPFL marks release candidates and final versions.  If Martin states to the community, "EPFL is no longer going to mark milestones, release candidates, or final versions," then the community will have to mobilize to figure out how to make those determinations.  But until that statement is made, I expect EPFL to be the authority on milestones and releases.

I have already offered to host Scala on the scala-tools.org CI server.  I reiterate that offer.  This will reduce the burden on EPFL to publish builds.  Further, if it is so burdensome to create milestone builds and publish them to scala-tools.org (which replicates to the main Maven repositories), I'm sure we can arrange to have someone in the community pull tagged code from EPFL's SVN repository and do builds.

So, even in this politely worded note, you've told the community that EPFL doesn't really care about the communities needs, which in my opinion is not a polite message.

David

Again, if the testing suite does not pass there will be no nightly pushed
out, so all of the nightly builds that do become visible are good
candidates, as far as we can tell.

Thank you again for your message, I hope my reply can be of some help. f
you have further suggestions about this process however, or require
additional information, please just let me know.
Toni

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

On Sat, Oct 3, 2009 at 1:58 PM, Jorge Ortiz wrote:
> I don't want to end on a bad note. Scala is a ground-breaking language and I
> appreciate all the effort that EPFL has put into it. But from where I'm
> standing, things can't continue they way they've been, so something has to
> change.

I agree, something has to change. But what exactly?

I think we're all agreed that enterprise-level support for Scala is
necessary for the peace of mind of its early adopters and for its
wider uptake.

However, I can't agree with the implication that it ought to be EPFL
that provides it, and free of charge to boot. If you want
enterprise-level support you should to go to an organization which is
set up to provide it (mine for example, there will be others).

Where that level of support isn't needed or isn't affordable the
community needs to help. All the major software packages you mention
can be tested against Scala release candidates quite independently,
outside of EPFL: the community can and should do that testing, provide
minimally reproducible test cases, and report back to EFPL in the lead
up to and during the release process.

To some extent this is being done, but not systematically enough.

So the process change I would advocate is one which formalizes
community testing of non-EPFL projects against EPFL releases, release
candidates and trunk and facilitates the feedback of reports and
patches to EPFL in a useful form.

Let's call it a community driven Q/A process.

Any takers?

Cheers,

Miles

Perhaps we can get a few of us together to contribute to a hudson cluster that will build against scala nightlies all the various testing libraries and community projects on all the desired "supported" platforms.  We had some internal discussions on this, but perhaps we collect interested parties to formalize this.  The requirements (as I see them);

• Automated  (No one person has that much time)
  
• Good Reporting (everyone can find the info on builds)
• Financial burden not on one person (i.e. community can contribute compute resources)
• Safety/Security (keep the thing prone from hacking)

I'm debating even having virtual machines that we could pass to interested parties (that sign some form of agreement first) that they could run and join the "testing cluster"

Anyone else interested in the idea?

- Josh

On Sat, Oct 3, 2009 at 9:50 AM, Miles Sabin <miles@milessabin.com> wrote:

On Sat, Oct 3, 2009 at 1:58 PM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:
> I don't want to end on a bad note. Scala is a ground-breaking language and I
> appreciate all the effort that EPFL has put into it. But from where I'm
> standing, things can't continue they way they've been, so something has to
> change.

I agree, something has to change. But what exactly?

I think we're all agreed that enterprise-level support for Scala is
necessary for the peace of mind of its early adopters and for its
wider uptake.

However, I can't agree with the implication that it ought to be EPFL
that provides it, and free of charge to boot. If you want
enterprise-level support you should to go to an organization which is
set up to provide it (mine for example, there will be others).

Where that level of support isn't needed or isn't affordable the
community needs to help. All the major software packages you mention
can be tested against Scala release candidates quite independently,
outside of EPFL: the community can and should do that testing, provide
minimally reproducible test cases, and report back to EFPL in the lead
up to and during the release process.

To some extent this is being done, but not systematically enough.

So the process change I would advocate is one which formalizes
community testing of non-EPFL projects against EPFL releases, release
candidates and trunk and facilitates the feedback of reports and
patches to EPFL in a useful form.

Let's call it a community driven Q/A process.

Any takers?

Cheers,


Miles

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

On Sat, Oct 3, 2009 at 2:57 PM, Josh Suereth wrote:
> Perhaps we can get a few of us together to contribute to a hudson cluster
> that will build against scala nightlies all the various testing libraries
> and community projects on all the desired "supported" platforms.  We had
> some internal discussions on this, but perhaps we collect interested parties
> to formalize this.  The requirements (as I see them);
>
> Automated  (No one person has that much time)
> Good Reporting (everyone can find the info on builds)
> Financial burden not on one person (i.e. community can contribute compute
> resources)
> Safety/Security (keep the thing prone from hacking)
>
> I'm debating even having virtual machines that we could pass to interested
> parties (that sign some form of agreement first) that they could run and
> join the "testing cluster"
>
> Anyone else interested in the idea?

Yes, this is exactly what we should be doing ...

Cheers,

Miles

I was wondering if the time is ripe for a non-profit Scala Software Foundation. Martin's team seems overloaded with too many concerns.
On Oct 3, 2009, at 15:58, Jorge Ortiz wrote:

I've been sitting on a response to this thread for a while. I don't mean to beat a dead horse or to reopen old wounds, but I think the underlying issues here are still unresolved and should be addressed.

There's a Bjarne Stroustrup quote that's been floating around Twitter for a couple of days: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." I think it's a testament to Scala's great usefulness and even greater potential that people can get so worked up about even very little things. Even though I might complain, I think it's important not to lose sight of all the work that has gone into Scala. I'm sure I'm not alone in appreciating all the hard work that Martin and the entire team at EPFL have put into Scala. You've made a truly compelling programming language; so compelling that it's getting popular.

Toni, in particular, has done a great job engaging with the community, keeping the website up-to-date, posting new polls and blog posts, gardening Trac, baby-sitting the build and release process, etc. When scala-blogs.org was started almost two years ago, there was very little blogging about Scala. It's incredibly satisfying to see that the official scala-lang.org now posts more blog content than scala-blogs.org, and that there's a burgeoning interest in Scala among the wider blogosphere. I also really appreciate, Toni, your work (above and beyond the call of duty) to backport a patch for a critical bug to the 2.7.x branch. It's comforting to know that branch hasn't been completely abandoned, as some people may be stuck on it long after 2.8.0 has been released.

That said, sometimes I feel that EPFL is out of touch with the needs of Scala's users. I imagine there's a vanishingly small number of non-trivial Scala projects (other than the compiler itself) that don't depend on one of Scalacheck, ScalaTest, or Specs. Real projects require real testing, and most Scala projects use one or more of these testing libraries for their tests. Taking as a given that Scala releases are binary incompatible, a release of Scala that is not known to work with these three libraries is, for all practical purposes, also not known to be generally useful. It is also important that a release of Scala work with some other popular projects which, because of their nature as libraries, frameworks, or tools, have a lot of code which depends on them. Projects in this last category that come to mind: Lift, SBT, Configgy, Akka, Scalax, Scalaz, and probably more that I'm forgetting. If these critical projects don't work with a given Scala release, then many more projects which depend on them won't be able to work with that Scala release either. If users can't trust that their libraries will work with future Scala releases, adding library dependencies to a project becomes a real liability.

For another example, take my employer, LinkedIn. Our infrastructure is organized around a service-oriented architecture. A single service, when pushed to production, might be running on dozens of machines and handling millions of requests per day. Our services are expected to run for weeks and months without interruption. In such a scenario, even small memory leaks are completely unacceptable, and the only uncertainty with respect to subtle concurrency bugs is when (not if) they will rear their ugly heads. Given this, it's extremely alarming to find that precisely such bugs (Ticket #1006), -in the core of the language-, have been known about for over a year and have first been ignored and later disputed. It's bad enough when bugs are in the standard library, but at least those can be worked around (more on this later). But when the bugs are in the core language, there's very little a user can do to avoid them.

LinkedIn is also stuck using Java 1.5. Our engineers overwhelmingly use Macs for development, and bugs in Apple's 1.6 JDK prevent us from upgrading to 1.6. I'm sure LinkedIn is not the only company that unfortunately needs to stay on 1.5 way past it's expiration date. We only have a few hundred engineers; it should be relatively trivial (compared to other, much larger, software shops) for us to migrate to 1.6, but we can't. Which leads us to bug #2380. Given how implicits work, Scala can't claim to support Java 1.5 unless it's compiled against Java 1.5. Frankly, this bug terrifies me. I have no idea where or how it might strike, and it will lurk in utmost silence until it's ready to kill.

Now, I've been using Scala long enough that I know where the major potholes in the standard libraries are, and I've tried to communicate them to my coworkers. Don't use Source, it won't actually close the file. Don't use immutable.Map, it's not actually immutable. Avoid collection.jcl, it's totally broken. From a purely self-centered perspective, it might actually be good for me that Scala is so buggy. I know where some of the bugs are, and that knowledge makes me valuable to people who aren't as familiar with Scala's deficiencies. But the truth is I don't want to be valuable for knowing how badly Scala is broken. I'd much rather be valuable for being able to show other people how awesome Scala is. Everyone expects a new technology to have some warts. That's understandable and forgivable. What's inexcusable is when fixes are handed to EPFL, sometimes on a silver platter, and either ignored or rejected. David MacIver contributed the actually-immutable IntMap and TreeHashMap over a year ago, yet immutable.Map still makes "immutable"-but-really-mutable-and-synchronized HashMaps. Daniel Spiewak was less lucky. He contributed his immutable persistent Vector 11 months ago, but lacking commit rights, his excellent work has languished in ticket #1509 that entire time. And it's probably best if we all just forgot about the time someone tried to fix Source.

Now, it's bad enough when the standard libraries are broken. That's annoying, but ultimately avoidable. But what happens when core language features are broken? My advice to other Scala users rings increasingly hollow. What am I supposed to say? Don't expect @volatile to work (#2424)? Don't use "finally" (#2392)?

Finally, that brings us to the topic of the 2.7.6 release. I, and surely others, had come to expect RC releases before a final release. Even in the best of times the process wasn't perfect, but it was better than nothing. (For much of 2.7.x I was responsible for porting Lift to new versions of Scala. After an RC came out, it was a race against the clock to try to compile Lift, because EPFL rushed towards -final and Lift can't compile until Specs and Scalacheck do.) What happened to the process? More importantly, how is it going to be prevented from happening again? Who needs to approve a release before it goes out? It's been stated that EPFL isn't secretive: Svn and Trac are out in the open. This may be true, but EPFL is hardly transparent. Even PaulP, -the author of the patch-, wasn't aware that it was being released. And he's more plugged in than most. He has insight into the scala-devel list, which--if not secretive--is certainly opaque.

I truly despise being the person to push for -more- process, but unfortunately processes exist for good reasons. A Scala release is for all practical purposes useless if it doesn't work with the three major testing frameworks. Furthermore, a Scala release is significantly crippled if it doesn't work with the more popular of the Scala-based libraries, frameworks, and tools listed above. At the very least, a plurality of these projects should be confirmed to compile and pass tests with a new Scala version before it can be considered final. LinkedIn has, by necessity, a very conservative process for vetting external libraries and releasing code. It would be unreasonable to expect a Scala release to wait until LinkedIn had compiled and tested all it's code against a release candidate before making a release final, but knowing that a particular Scala version compiled many disparate open source projects would give me substantial peace of mind to know that release was probably ok.

Now, the issue of transparency (really, opacity) runs deeper than just notifying the community of an imminent release. EPFL has a long-standing policy of not committing releases (particularly 2.8) to any fixed schedule, under the philosophy that it'll be ready when it's ready. I've been a strong (and sometimes vocal) supporter of this policy. I know these things take time and feel strongly that they shouldn't be rushed. That said, there's been absolutely no transparency on the part of EPFL surrounding the 2.8 release. In particular, what conditions need to be met before 2.8 is released? Which tickets are blockers? Which tickets can we expect to see fixed (that aren't already fixed in trunk)? If tickets are too specific, what general steps need to happen before a 2.8 release?

Transparency also applies to contributions. There's no policy on what non-breaking contributions will be accepted into the standard library. Nor a policy on what breaking changes are acceptable for minor or major releases. It's all, I'm afraid, quite arbitrary. IntMap goes in because David MacIver can commit it himself and no one feels strongly enough to object. Vector doesn't go in because Daniel Spiewak can't commit it himself and no one feels strongly enough to include it. Collection.jcl disappears without a trace or even a period of deprecation because no one can be bothered to reimplement it for 2.8 collections, but Source lives on for years and years in this zombie undead state because we can't tolerate a breaking change. (I certainly don't want to be interpreted as arguing for jcl's return. As far as I'm concerned, good riddance.) Even PaulP--who's more plugged in than most, has visibility into the opaque scala-devel, and has rights to commit his code--even PaulP frequently expresses uncertainty about whether his contributions will be simply ignored or rejected outright.

People at EPFL frequently state they lack the bandwidth to handle more Trac tickets, more process, slower releases, bugfix backports for Scala 2.7.x, support for Java 1.5, fixes for broken libraries, vetting user contributed code, etc. Unfortunately, all these things are essential if Scala is going to be credible for real, production use. How can these conflicting needs can be worked out?

I don't want to end on a bad note. Scala is a ground-breaking language and I appreciate all the effort that EPFL has put into it. But from where I'm standing, things can't continue they way they've been, so something has to change.

--j

On Thu, Sep 24, 2009 at 3:36 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Wed, Sep 23, 2009 at 4:58 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

On Thu, September 24, 2009 12:50 am, Seth Tisue wrote:
> If it were just a litle easier for people to test the new stuff, I think
> a lot of problems could get sorted out sooner rather than later.
> [...]
> Hopefully this is a polite contribution to a thread that has gotten
> rather tense.  Cheers,
>

Seth,

Thank you for your message and for your explanation. Politeness is always
welcome :)

I look forward to a new era where EPFL has a policy of politeness to people in the community.  I will certainly reciprocate.

However, branding my requirements as "Maven centric" is not polite.  Releasing 2.7.6 without any discussion with the community and not apologizing for the quality of the release are not polite.

Dismissing every one of my ticket submissions over the last year with a wave of a hand and a "I've looked at my code and it looks fine to me," is not polite.

I am direct and confrontational because this is the only strategy that I have seen to be effective with EPFL.  I would certainly like to have a more polite and respectful environment, as we do on the Lift list.
 

Concerning setting up snapshots, I recall that when Josh sent that message
I replied stating that the various features that end up in trunk are
rarely synchronized in terms of development cycle. As a consequence, we
can rarely pinpoint snapshots that are "better" than others: trunk is
prone to continuous changes.

This strikes me as a failure of process.  I understand that Scala is complex and that there is a lot of coordination between contributors.  However, rolling a feature into trunk, letting the feature settle, releasing a milestone, and getting feedback on the milestone, and repeating the process for the material changes to Scala would (1) be a way to test each new feature and (2) be a significantly better way to get feedback from Scala users because the feedback would generally be isolated to a single "big change".

Scala is being advertised by EPFL as ready for enterprise use.  In order to come close to meeting that billing, there must be a process in place for integrating significant changes.  "Test whatever's around on a give day" is not such a process.
 

Our fundamental metric to decide when a
snapshot is reasonably stable is that the test suite passes; at that stage
it is, at the best of our intentions, ready for further testing by the
user community. We then rely on that feedback to further improve our
testing suite, of course.

Part of the test suite should include building the popular Scala projects including Lift, ScalaZ, Configgy, SBT, ScalaTest, ScalaCheck, Specs etc.  If those packages build and pass their own internal tests, you have a good amount of coverage in terms of the way Scala is being used in the wild.

Please don't respond with "we don't have the time/resources."  Please see my above assertion about the way that Scala is being advertised by EPFL.  Further, every resource allocation decision has impacts.  If EPFL decides not to invest the 2-man weeks that it would take to set up a test harness that would build the above projects, there are two other options: (1) community does it or (2) nobody does it.  If it's the former, EPFL is asking the community to invest $10K-$20K of someone's time to do the work.  If it's the latter, EPFL will continue to have release disasters (what's the polite way to describe the 2.7.6 release?)
 

Pushing the resulting nightly files to the snapshot repo or to a
mini-repository is essentially the same for us; we entirely rely on the
community for Maven support (we do not have the internal resources to
follow that as well). How to organize the mini-repos is entirely up to the
scala-tools site, however. If you decide to implement such a solution,
please just let us have an updated deployment build file and we'll be
happy to update the nightly script to accommodate the change.

As for detecting when it might be worth creating more permanent
checkpoints for testing, the best source to gather that information is of
course the commit log:

http://lampsvn.epfl.ch/trac/scala/log/scala/trunk?limit=100&mode=stop_on_copy&format=rss

It's all in the open: we don't hide that information.

I will be happy to respond in kind.  If it's the policy that any information that one needs can be found in commit notes, then it will be the Lift policy that anything that EPFL wants from Lift can be found in the Lift repository.  That doesn't feel too good, does it?  It doesn't give you the sense that we're working with you.  It certainly doesn't seem polite.

EPFL has weekly meetings on Tuesdays.  I'm sure there could be an agenda item, "is the current snapshot a milestone candidate?" at every meeting.  It's a simple decision.  If the decision is "yes" then either create a tag and send a note to internals.
 

If you need to
publish certain snapshots at particular points in time, your best bet is
just checking the log in order to decide when that is most appropriate.

The problem becomes, "what is an authoritative Scala milestone/release?"  If EPFL wants to cede making those decisions to the community, that is huge change in the existing process where EPFL marks release candidates and final versions.  If Martin states to the community, "EPFL is no longer going to mark milestones, release candidates, or final versions," then the community will have to mobilize to figure out how to make those determinations.  But until that statement is made, I expect EPFL to be the authority on milestones and releases.

I have already offered to host Scala on the scala-tools.org CI server.  I reiterate that offer.  This will reduce the burden on EPFL to publish builds.  Further, if it is so burdensome to create milestone builds and publish them to scala-tools.org (which replicates to the main Maven repositories), I'm sure we can arrange to have someone in the community pull tagged code from EPFL's SVN repository and do builds.

So, even in this politely worded note, you've told the community that EPFL doesn't really care about the communities needs, which in my opinion is not a polite message.

David

Again, if the testing suite does not pass there will be no nightly pushed
out, so all of the nightly builds that do become visible are good
candidates, as far as we can tell.

Thank you again for your message, I hope my reply can be of some help. f
you have further suggestions about this process however, or require
additional information, please just let me know.
Toni

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

-- 
   __~O
  -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

As a guy who lives in the grey zone between the inside and the outside,
I have two reactions to jorge's email:

1) Broad agreement.
2) Optimism that a way forward which makes everyone happy would not be
that hard to come by. (As happy as a class of people who think too
frequently about optimization can be, anyway.)

I don't think #2380 needs to remain terrifying (although the fact that
it's closed isn't good, is there an open ticket documenting the general
issue?) It does add to the number of things which have to be thought
about to have unsurprising releases, which points back toward having
more transparent and reproducible processes.

All~

It seems to me that this problem cannot be a new one.  How do python or perl handle it?

Matt

On Oct 3, 2009 11:39 AM, "Paul Phillips" <paulp@improving.org> wrote:

As a guy who lives in the grey zone between the inside and the outside,
I have two reactions to jorge's email:

 1) Broad agreement.
 2) Optimism that a way forward which makes everyone happy would not be
that hard to come by.  (As happy as a class of people who think too
frequently about optimization can be, anyway.)

I don't think #2380 needs to remain terrifying (although the fact that
it's closed isn't good, is there an open ticket documenting the general
issue?) It does add to the number of things which have to be thought
about to have unsurprising releases, which points back toward having
more transparent and reproducible processes.

--
Paul Phillips      | If this is raisin, make toast with it.
Stickler           |
Empiricist         |
pp: i haul pills   |----------* http://www.improving.org/paulp/ *----------

On Sat, Oct 03, 2009 at 11:43:42AM -0400, Matt Fowles wrote:
> It seems to me that this problem cannot be a new one. How do python
> or perl handle it?

By shipping source?

The problem is that bytecode is an intermediate representation, and
scala's semantics imply different bytecode generation depending on
compilation time features like whether String has an isEmpty method.
It's been a while since I used perl and forever since I used python, but
it is the intermediary of bytecode combined with scala's "accomodation
via implicit" which brings the pain.

On Oct 3, 2009, at 5:58 AM, Jorge Ortiz wrote:

> Now, the issue of transparency (really, opacity) runs deeper than
> just notifying the community of an imminent release. EPFL has a long-
> standing policy of not committing releases (particularly 2.8) to any
> fixed schedule, under the philosophy that it'll be ready when it's
> ready. I've been a strong (and sometimes vocal) supporter of this
> policy. I know these things take time and feel strongly that they
> shouldn't be rushed. That said, there's been absolutely no
> transparency on the part of EPFL surrounding the 2.8 release. In
> particular, what conditions need to be met before 2.8 is released?
> Which tickets are blockers? Which tickets can we expect to see fixed
> (that aren't already fixed in trunk)? If tickets are too specific,
> what general steps need to happen before a 2.8 release?

To the issue of transparency, I feel there's not enough open
communication. I understand there are weekly Scala meetings where
many issues are worked out. As Karl Fogel, one of the founding
developers of Subversion and the author of "Producing Open Source
Software":

http://producingoss.com/en/setting-tone.html#avoid-private-discussions

"""Even after you've taken the project public, you and the other
founders will often find yourselves wanting to settle difficult
questions by private communications among an inner circle.... All the
obvious disadvantages of public list discussions will loom palpably in
front of you: the delay inherent in email conversations, the need to
leave sufficient time for consensus to form, the hassle of dealing
with naive volunteers who think they understand all the issues but
actually don't (every project has these; sometimes they're next year's
star contributors, sometimes they stay naive forever), the person who
can't understand why you only want to solve problem X when it's
obviously a subset of larger problem Y, and so on.

Don't do it."""

On the Subversion project, we use IRC for quick chats, but the rule is
no decision is final unless it's discussed on the mailing list. The
only private conversations we have in the Subversion community are
wether to grant commit rights to a new developer, any corporate,
trademark and legal issues.

For Scala, ideally all communication should be done in the open so
anyone in the community can participate if interested. If the weekly
meetings are a must, make them viewable on Skype or some other video
sharing solution for the community to listen in on and participate by
IM. I bet people would write and post notes for the meeting which
many people would find very useful.

Regards,
Blair

Hi Jorge,

Thanks for your mail. It's good to bring these things out to discuss
them, and I understand your frustration.

First, let me say that the 2.7.6 glitch should never have happened and
I'll make sure it won't happen again. In the future we will always
ship RC's no matter how trivial the change seems.
I apologize for the grief this has caused.

I realize that we made this promise already once earlier when a
similar slipup happened. So it happening again looks bad. Don't these
people learn from their past mistakes, you ask?
Maybe one reason is that they are no longer the same people. Every new
generation of Ph.D. students and postdocs has to relearn these things
from scratch. Another reason was that 2.7.6 was really on a different
level from previous problems. It was a backport of a single line of
code change where we had assurances from people (I think it was
LinkedIn, but I might be wrong) that it worked fine for their
installation. All that was required was to make this the offical
blessed release. So it seemed like an innocuous and well-tested fix,
but it wasn't. Well, we have learned and I'll promise that there won't
be another release coming out without an RC first, no matter how
trivial the delta looks.

The other question, is how did the bug happen, and there we really get
more to the core of the difficulties we are facing. The problem was a
tricky issue where the type checker and the pickler/unpickler interact
with Java compatibility. It was a matter how to serialize existential
types that correspond to Java wildcards. Now, there are very few
people on this planet who know *precisely* what existential types are,
and how they are implemented in the Scala type checker. Essentially,
that's me, and nobody else. Paul tried his best to provide a patch
which closed several tickets but admitted he did not know too well
what he was doing and left the final review to me. I have a huge
stacks of such reviews, and this one would have taken me at least a
day to do properly, so I accepted the patch on the evidence that the
tickets were closed, and that it did not look unreasonable at first
sight. Things went into trunk, people backported the patch for their
own systems because it was critical to them, and everything seemed to
work fine.

So, how can we avoid this in the future? Can we better share the work
on the Scala compiler, maybe by educating more people about it? I have
to say I am fortunate now to have the help of Paul, and Adriaan in
this, but I have become very sceptical about opening this up further.
Modern type checkers and inferencers are extremely evolved and subtle
beasts. I know of no modern statically typed language where the type
checker is not under the exclusive control of a single person. That
holds for Haskell, Ocaml, and I believe also for Java and C#. It
really is a job that demands enormous expertise and a view of the
whole. The main problem we are facing is that the people who do the
Java or C# tor F# type checker do this as a full-time job. Besides the
type checker, here's the list of things I also had to do over the last
year:

- write the collection libraries (by itself a full-time job)
- write the new compiler support for the Eclipse plugin (again, full-time job)
- evolve the Scala spec
- manage the Scala team at EPFL (full-time job)
- coordinate the hundreds of tickets and patches, which all too often
refer to me as final authority,
- organize the Scala community and spread the word
- write a lot of grant proposals to get the necessary funding for all this
- find people to hire with that money
- teaching (yes I need to do that also)
- research (although I get to do precious little of that with all the
other activities).

You see where the problems lie, now, I guess. So the only way out must
be delegation.
I cannot, and will not, delegate the type checker and the spec. If I
did that I can virtually guarantee that bit rot would set in quickly,
and in two years time we'd be in a situation where we'd have to throw
everything away and rewrite from scratch. So that leaves the other
things. I believe in retrospect I should have taken on neither the
collection libraries not the Eclipse plugin. But they seemed to be
such awful holes that something had to be done, and nothing was
forthcoming, I am afraid. It's not lack of patches, there was a steady
stream of those against collections. But in the balance all those
patches made the situation worse, not better, because there was no
maintainer with a single vision. We need more visionaries! That's how
the community could really help. Take responsibility for a whole area,
do it to the very end, and take responsibility for maintaining what
you have done. There's not a lack of areas where we would embrace help
like this. Among them are

ScalaDoc
I/O
Modularization
Swing
Java Source output so that GWT works
Actors

In some of these cases (e.g. I/O) nothing much was done and one can
start from scratch. In others (e.g. actors) there's a large code base
out there and any further evolution would have to
take that into account. Previously, all too often there was a plan to
start a great new feature, but nothing ever came out of it
(Discussions either drift to what repo to use or what license and
things stop there). I hope the current efforts on I/O and
Modularization will not suffer the same fate.

Another thing that would help is: short code examples detailing a bug
report. There were several tickets raised against lift where we were
told to simply check out lift and see for ourselves. We all know that
localization of a problem in a large code base is very time consuming.
Who is well placed to do it? Well, probably people knowing the type
checker (that's where most of the bugs were) and people knowing lift.
I'm afraid the set of people satisfying both criteria is empty. So
it's either the people knowing he type checker (i.e. me) or someone
knowing lift. Since I don't have the time to do it, my strategy was to
wait until somebody else reported a bug that looked similar with a
shorter code example and fix this one. I am sorry if that made it look
like we were intentionally ignoring lift bugs. That's not what it was,
as far as I am concerned.

I'll respond to your other points in a separate mail.

Cheers

On Saturday October 3 2009, Blair Zajac wrote:
> ...
>
> http://producingoss.com/en/setting-tone.html#avoid-private-discussion
>s
>
> """Even after you've taken the project public, you and the other
> founders will often find yourselves wanting to settle difficult
> questions by private communications among an inner circle.... All the
> obvious disadvantages of public list discussions will loom palpably
> in front of you: the delay inherent in email conversations, the need
> to leave sufficient time for consensus to form, ...
>
> Don't do it."""
>
> On the Subversion project, we use IRC for quick chats, but the rule
> is no decision is final unless it's discussed on the mailing list.
> The only private conversations we have in the Subversion community
> are wether to grant commit rights to a new developer, any corporate,
> trademark and legal issues.
>
> For Scala, ideally all communication should be done in the open so
> anyone in the community can participate if interested. ...

While this is neither here nor there at the moment, we might hope that
better communications technologies (yeah, I'm thinking Google Wave)
might significantly, even fundamentally, improve this situation. Until
then, the dilemma remains, I guess.

> Regards,
> Blair

Randall Schulz

Hi Jorge,

Here's the second part of my response, where I try to address some of
the issues you have raised in more detail.

> That said, sometimes I feel that EPFL is out of touch with the needs of
> Scala's users. I imagine there's a vanishingly small number of non-trivial
> Scala projects (other than the compiler itself) that don't depend on one of
> Scalacheck, ScalaTest, or Specs. Real projects require real testing, and
> most Scala projects use one or more of these testing libraries for their
> tests. Taking as a given that Scala releases are binary incompatible, a
> release of Scala that is not known to work with these three libraries is,
> for all practical purposes, also not known to be generally useful. It is
> also important that a release of Scala work with some other popular projects
> which, because of their nature as libraries, frameworks, or tools, have a
> lot of code which depends on them. Projects in this last category that come
> to mind: Lift, SBT, Configgy, Akka, Scalax, Scalaz, and probably more that
> I'm forgetting. If these critical projects don't work with a given Scala
> release, then many more projects which depend on them won't be able to work
> with that Scala release either. If users can't trust that their libraries
> will work with future Scala releases, adding library dependencies to a
> project becomes a real liability.
>
I have already pledged that there won't be a Scala release anymore
without an RC. It would probably be a good idea to set up a system
where core projects get tested against the RC quickly and we would
turn an RC into final only if the feedback is positive. If you or
other core project leaders want to figure something like that out,
that would be great!

> For another example, take my employer, LinkedIn. Our infrastructure is
> organized around a service-oriented architecture. A single service, when
> pushed to production, might be running on dozens of machines and handling
> millions of requests per day. Our services are expected to run for weeks and
> months without interruption. In such a scenario, even small memory leaks are
> completely unacceptable, and the only uncertainty with respect to subtle
> concurrency bugs is when (not if) they will rear their ugly heads. Given
> this, it's extremely alarming to find that precisely such bugs (Ticket
> #1006), -in the core of the language-, have been known about for over a year
> and have first been ignored and later disputed. It's bad enough when bugs
> are in the standard library, but at least those can be worked around (more
> on this later). But when the bugs are in the core language, there's very
> little a user can do to avoid them.
>
> LinkedIn is also stuck using Java 1.5. Our engineers overwhelmingly use Macs
> for development, and bugs in Apple's 1.6 JDK prevent us from upgrading to
> 1.6. I'm sure LinkedIn is not the only company that unfortunately needs to
> stay on 1.5 way past it's expiration date. We only have a few hundred
> engineers; it should be relatively trivial (compared to other, much larger,
> software shops) for us to migrate to 1.6, but we can't. Which leads us to
> bug #2380. Given how implicits work, Scala can't claim to support Java 1.5
> unless it's compiled against Java 1.5. Frankly, this bug terrifies me. I
> have no idea where or how it might strike, and it will lurk in utmost
> silence until it's ready to kill.
>
I think this one is easy: For 2.8 there will be a separate 1.5 build
which will be built on a 1.5 system.

> Now, I've been using Scala long enough that I know where the major potholes
> in the standard libraries are, and I've tried to communicate them to my
> coworkers. Don't use Source, it won't actually close the file. Don't use
> immutable.Map, it's not actually immutable. Avoid collection.jcl, it's
> totally broken. From a purely self-centered perspective, it might actually
> be good for me that Scala is so buggy. I know where some of the bugs are,
> and that knowledge makes me valuable to people who aren't as familiar with
> Scala's deficiencies. But the truth is I don't want to be valuable for
> knowing how badly Scala is broken. I'd much rather be valuable for being
> able to show other people how awesome Scala is. Everyone expects a new
> technology to have some warts. That's understandable and forgivable. What's
> inexcusable is when fixes are handed to EPFL, sometimes on a silver platter,
> and either ignored or rejected. David MacIver contributed the
> actually-immutable IntMap and TreeHashMap over a year ago, yet immutable.Map
> still makes "immutable"-but-really-mutable-and-synchronized HashMaps. Daniel
> Spiewak was less lucky. He contributed his immutable persistent Vector 11
> months ago, but lacking commit rights, his excellent work has languished in
> ticket #1509 that entire time. And it's probably best if we all just forgot
> about the time someone tried to fix Source.
>
Over this whole year we were busy with 2.8. There were no Scala 2.7
releases with new features. All that was done was fixes of certain
critical bugs. So I believe much of your criticism really has to do
with the fact that there was too much of a leap between 2.7 and 2.8.
On my side, I can say that I completely underestimated the
difficulties were were facing with the collections design and with
arrays, but I do not see how things could have been broken up
otherwise. Regarding David's implementation, the fact is that
immutable.Map is still faster than TreeHashMap in most situations, so
there was a reason for keeping it. Regarding Daniel Spiewacks
contribution, I happened to deal with his ticket today before I saw
your mail (see my last comment on the ticket). I have very high hopes
that there will be a good persistent vector implementation in 2.8.

> Now, it's bad enough when the standard libraries are broken. That's
> annoying, but ultimately avoidable. But what happens when core language
> features are broken? My advice to other Scala users rings increasingly
> hollow. What am I supposed to say? Don't expect @volatile to work (#2424)?
> Don't use "finally" (#2392)?
>
I think here you are exaggerating. Both tickets are very fresh.
@volatile is 2 days old and is being worked on. The finally problem is
already fixed and was even backported into the 2.7.7RC. Believe me, if
we get a bug report about wrong code being generated we take that very
seriously and react immediately.

> Finally, that brings us to the topic of the 2.7.6 release. I, and surely
> others, had come to expect RC releases before a final release. Even in the
> best of times the process wasn't perfect, but it was better than nothing.
> (For much of 2.7.x I was responsible for porting Lift to new versions of
> Scala. After an RC came out, it was a race against the clock to try to
> compile Lift, because EPFL rushed towards -final and Lift can't compile
> until Specs and Scalacheck do.) What happened to the process? More
> importantly, how is it going to be prevented from happening again? Who needs
> to approve a release before it goes out? It's been stated that EPFL isn't
> secretive: Svn and Trac are out in the open. This may be true, but EPFL is
> hardly transparent. Even PaulP, -the author of the patch-, wasn't aware that
> it was being released.

Maybe my prvious explanations have now shed some light on this matter.
For us it looked like a minor thing, that was one of the many items
discussed at the Scala meeting. We won't follow the same procedure for
releases anymore, in any case.

> Now, the issue of transparency (really, opacity) runs deeper than just
> notifying the community of an imminent release. EPFL has a long-standing
> policy of not committing releases (particularly 2.8) to any fixed schedule,
> under the philosophy that it'll be ready when it's ready. I've been a strong
> (and sometimes vocal) supporter of this policy. I know these things take
> time and feel strongly that they shouldn't be rushed. That said, there's
> been absolutely no transparency on the part of EPFL surrounding the 2.8
> release. In particular, what conditions need to be met before 2.8 is
> released?

When we are reasonably sure that the compiler, the libraries and the
Eclipse plugin work resonably well. And when all the major tools build
against it. I can't be more specific than that really.

> Which tickets are blockers? Which tickets can we expect to see
> fixed (that aren't already fixed in trunk)? If tickets are too specific,
> what general steps need to happen before a 2.8 release?
>
Tickets are definitely too specific.

> Transparency also applies to contributions. There's no policy on what
> non-breaking contributions will be accepted into the standard library.

I am a bit at a loss how to formulate such a policy. I have offered to
delegate the task of library czar, and Paul has graciously accepted to
take this on in addition to the other things he does. Maybe he will
develop one.

> Nor a
> policy on what breaking changes are acceptable for minor or major releases.

We will not accept breaking language changes for minor releases. As to
libraries, it's difficult. You have to weigh possible breakage against
the cost of keeping the wrong implementation. Every case is different.
It depends how central the library is and how important the fix is.

> It's all, I'm afraid, quite arbitrary. IntMap goes in because David MacIver
> can commit it himself and no one feels strongly enough to object. Vector
> doesn't go in because Daniel Spiewak can't commit it himself and no one
> feels strongly enough to include it.

No, it was because Vector arrived at a time were 2.7 was frozen for
new features.

> Collection.jcl disappears without a
> trace or even a period of deprecation because no one can be bothered to
> reimplement it for 2.8 collections,

So, you are proposing, I should be bothered to reimplement
collection.jcl collections? Despite the fact that, as you write, `it's
totally broken'. If not me, who else? Why not you?

> but Source lives on for years and years
> in this zombie undead state because we can't tolerate a breaking change.

No, but because nobody came trough with a different I/O library. It
was not for lack of asking but nothing whatsoever materialized until
now. Paul has tried, but there was such a storm of resistance that he
withdrew what he did.

> certainly don't want to be interpreted as arguing for jcl's return. As far
> as I'm concerned, good riddance.) Even PaulP--who's more plugged in than
> most, has visibility into the opaque scala-devel, and has rights to commit
> his code--even PaulP frequently expresses uncertainty about whether his
> contributions will be simply ignored or rejected outright.
> People at EPFL frequently state they lack the bandwidth to handle more Trac
> tickets, more process, slower releases, bugfix backports for Scala 2.7.x,
> support for Java 1.5, fixes for broken libraries, vetting user contributed
> code, etc. Unfortunately, all these things are essential if Scala is going
> to be credible for real, production use. How can these conflicting needs can
> be worked out?
>
Yes, that's a good question. I don't have good answers for this
really. As I wrote in my last mail, we need more people who take on
responsibility for large parts of Scala and its libraries. Patches are
welcome, but more important still would be to take over things
wholesale and see them through to the end.

> I don't want to end on a bad note. Scala is a ground-breaking language and I
> appreciate all the effort that EPFL has put into it. But from where I'm
> standing, things can't continue they way they've been, so something has to
> change.

I believe things will change for the better. Much of the frustration
has to do with the fact that we are facing a long-outstanding and very
difficult release with 2.8. Also staffing at EPFL looks now much
better than it did over the last year. In particular, I welcome
Adriaan Moors and Donna Malayeri as new postdocs as well as Hubert
Plociniczak and Alex Prokopec as Ph.D students.

Cheers

Hi Blair,

We are planning to open up the Scala meetings and to publish in the
future at least a protocol of what was decided. That decision was made
a couple of weeks ago, we just need time to convert parts of the
internal EPFL Wiki we use to support public visibility.

We have already opened up quite a bit with the creation of
scala-internals, and I think that has worked well, overall.

As to the other goal:

> On the Subversion project, we use IRC for quick chats, but the rule is no
> decision is final unless it's discussed on the mailing list.  The only
> private conversations we have in the Subversion community are wether to
> grant commit rights to a new developer, any corporate, trademark and legal
> issues.
>
I doubt we will go that far. The price of publicity is tangible. For
instance, on this thread alone, I have spent now 3 hours responding to
mails. I did that because I felt it was important. But in general in 3
hours of my time, I can fix tickets or work on critical core issues of
the system. I believe a compiler might have a different committer
profile from svn in that respect. If you disagree, tell me what
succesfull language that were designed and implemented in this totally
open way.

> For Scala, ideally all communication should be done in the open so anyone in
> the community can participate if interested.  If the weekly meetings are a
> must, make them viewable on Skype or some other video sharing solution for
> the community to listen in on and participate by IM.  I bet people would
> write and post notes for the meeting which many people would find very
> useful.

The Scala meetings are always a mixture of private and public. For
that reason we can't publish them on Skype. But we will publish
protocols, that should help.

Cheers

On Oct 3, 2009, at 11:16 AM, martin odersky wrote:

> Hi Blair,
>
> We are planning to open up the Scala meetings and to publish in the
> future at least a protocol of what was decided. That decision was made
> a couple of weeks ago, we just need time to convert parts of the
> internal EPFL Wiki we use to support public visibility.
>
> We have already opened up quite a bit with the creation of
> scala-internals, and I think that has worked well, overall.

Hi Martin,

Thanks, that's great news on the protocol reports. And yes, the
opening up has worked well.

> As to the other goal:
>
>> On the Subversion project, we use IRC for quick chats, but the rule
>> is no
>> decision is final unless it's discussed on the mailing list. The
>> only
>> private conversations we have in the Subversion community are
>> wether to
>> grant commit rights to a new developer, any corporate, trademark
>> and legal
>> issues.
>>
> I doubt we will go that far. The price of publicity is tangible. For
> instance, on this thread alone, I have spent now 3 hours responding to
> mails. I did that because I felt it was important. But in general in 3
> hours of my time, I can fix tickets or work on critical core issues of
> the system. I believe a compiler might have a different committer
> profile from svn in that respect. If you disagree, tell me what
> succesfull language that were designed and implemented in this totally
> open way.

Thanks for spending all the time on this. I appreciate it and it pays
off for the project.

I should clarify my comment on mailing lists. Not every decision is
discussed on the mailing list. The developer has a sense on how large
the design issue is, its impact on the code base and future
extensibility of the project and if the entire development community
should be aware of it; it's at the developer's discretion.

I helped on Perl 10 years ago and I don't recall any place where the
developers would discuss the language besides the mailing list. And
isn't gcc all in the open? Do they even have a large enough committer
base in one physical location where they could meet in person?

>
>> For Scala, ideally all communication should be done in the open so
>> anyone in
>> the community can participate if interested. If the weekly
>> meetings are a
>> must, make them viewable on Skype or some other video sharing
>> solution for
>> the community to listen in on and participate by IM. I bet people
>> would
>> write and post notes for the meeting which many people would find
>> very
>> useful.
>
> The Scala meetings are always a mixture of private and public. For
> that reason we can't publish them on Skype. But we will publish
> protocols, that should help.

Great!

Regards,
Blair

On Sat, Oct 03, 2009 at 12:16:23PM -0700, Blair Zajac wrote:
> I helped on Perl 10 years ago and I don't recall any place where the
> developers would discuss the language besides the mailing list. And
> isn't gcc all in the open? Do they even have a large enough committer
> base in one physical location where they could meet in person?

If there isn't a semi-private mailing list where people can speak
freely, then people will form an ad-hoc one as the need arises (by
emailing people directly.) I think there is a Lesser of Two Evils
implied by this Law of Unintended Consequences. You can't really say
that perl and gcc developers didn't email one another directly, because
nobody knows that.

Other things were also different ten years ago, but I'm not going to
discuss who's on my lawn and where they ought to be.

On Oct 3, 2009, at 12:41 PM, Paul Phillips wrote:

> On Sat, Oct 03, 2009 at 12:16:23PM -0700, Blair Zajac wrote:
>> I helped on Perl 10 years ago and I don't recall any place where the
>> developers would discuss the language besides the mailing list. And
>> isn't gcc all in the open? Do they even have a large enough
>> committer
>> base in one physical location where they could meet in person?
>
> If there isn't a semi-private mailing list where people can speak
> freely, then people will form an ad-hoc one as the need arises (by
> emailing people directly.) I think there is a Lesser of Two Evils
> implied by this Law of Unintended Consequences. You can't really say
> that perl and gcc developers didn't email one another directly,
> because
> nobody knows that.

Are you talking about a semi-private list for non-technical issues? I
totally see a need for that and agree with you. But for technical
issues, the only need I've seen is for a private list for security
issues so people following the dev list don't see the vulnerability
before a fix is prepared. I still maintain that all technical
discussions should be held somewhere public, IRC or mailing list.
Anytime someone on the private svn-full-committers list starts to
turns into a coding or design discussion, then somebody will ask that
the conversation be moved to the public dev list, we're pretty
rigorous about that.

Blair

On Sat, Oct 03, 2009 at 02:18:35PM -0700, Blair Zajac wrote:
> Are you talking about a semi-private list for non-technical issues? I
> totally see a need for that and agree with you.

I would say the border between technical issues and non-technical issues
is wide, disputed, and blurry.

Realize I'm the choir here. The public scala-internals list exists at
least in part because of pressure from me (of course that was back
before I was a committer) and as far as I'm concerned everything
possible should be done in the open. And with a view of both lists, I
can promise you that internals is everyone's default for technical
issues.

However some people are more, shall we say, fragile than others, and
deal a lot better with criticism or conflict (technical or otherwise) in
a semi-private context. For that reason alone I think scala-devel
serves a useful purpose.

I also think there's a good chance you are overestimating the
significance of the private list. Trust me, if you could see every
message on it you'd know very little more than you know now. It's what
transpires in the weekly meetings (and maybe other epfl real-life
settings) more than anything that needs more transparentization, and as
I believe has been stated, that is intended.

> So, how can we avoid this in the future? Can we better share the work
> on the Scala compiler, maybe by educating more people about it? I have
> to say I am fortunate now to have the help of Paul, and Adriaan in
> this, but I have become very sceptical about opening this up further.

We already have a (comparatively) easy route for those willing to
devote time and seeking familiarity with compiler internals,
presumably with the goal of being able to commit valuable fixes and
improvements for future language releases. I naturally include myself
in this list :)

I speak, of course, about the compiler plugins mechanism. This is far
less painful that having to directly modify the compiler source and
recompile, and also offers a much faster turnaround time. Perhaps it
would be possible to open up a mailing list or a wiki holding several
"cookbook" entries on how to handle a number of typical scenarios
within a compiler plugin (i.e. how the AST/types/symbols interact, how
to have your plugin recognize a custom annotation, what traits are
available to mixin to a plugin phase and when best to use them,
etc...)

Currently, it's difficult for those who actively work on compiler
internals to find the time for such an effort, but I honestly believe
it would be a valuable investment towards attracting future
committers, as well as a useful teaching resource for the internal use
of EPFL

This would also encourage and help people to submit a subset of
possible improvements without any risk of bitrot in the core source.

Hi Martin,

Thanks for taking the time to reply to these emails in detail.

On Sat, 2009-10-03 at 19:10 +0200, martin odersky wrote:
> I believe in retrospect I should have taken on neither the
> collection libraries not the Eclipse plugin. But they seemed to be
> such awful holes that something had to be done, and nothing was
> forthcoming, I am afraid.

I hope that once 2.8 is out and everyone is enjoying a better
collections library along with better IDE integration (not just Eclipse,
since I believe Netbeans is also using the new hooks), you will feel
more like "it was painful, but worth it". :) As you say, they were some
awful holes and it's great to see something done about them.

Also, I am happy to hear that a protocol of what is decided in the
weekly Scala meetings will be published.

Thanks,
Ismael