Just to clarify

Hi Toni,

On Fri, 2009-09-25 at 13:02 +0200, Antonio Cunei wrote:
> * If the community needs preliminary 2.8 releases that are known to be good
> enough for general testing, and to assist people with migrating to the new
> code base, then what you really want is a beta release.

I think this is where there is a communication gap. The community seems
to want something that is closer to an alpha release. A release that is
known to be incomplete, but that can be tested on some level. Something
between a random snapshot from trunk that passes the test suite (that is
still not thorough enough) and a beta.

The idea is that instead of going for several months of development
before a beta, one could release an alpha every 6-8 weeks (on average
and depending on the development itself). For example, in 2.8.x, a few
large features were added (new collections, new arrays, named and
default arguments, etc.). After one (or more, if necessary) big feature
lands on trunk, one could give it a week or two and then release an
alpha.

This would improve the feedback loop, issues (bugs and design problems)
would be found faster and projects would migrate to newer versions
sooner. It seems like a benefit all around with the exception of the
extra work to produce the release.

> The fact that the community is eager for code to be available for porting
> to won't change the fact that the code in trunk is exactly what it is:
> development code. The feedback we gather from users who try trunk is
> invaluable, but it not production code, nor code in which any particular
> feature is supposed to be complete. "Better" means beta: you need to wait a
> few more weeks.

EPFL may decide that this approach is what works best for you, but it's
certainly not the only way. Many (maybe even most) projects have
something between "random snapshot from trunk that passes tests" and a
beta as defined in the original message.

I should probably note that the current development process would be
less of an issue if the test suite was more comprehensive (this should
improve with time) and if there weren't so many binary incompatible
changes in trunk (unclear if this will improve).

Best,
Ismael

Ismael Juma wrote:
> Hi Toni,

Hi all,

>
> The idea is that instead of going for several months of development
> before a beta, one could release an alpha every 6-8 weeks (on average
> and depending on the development itself). For example, in 2.8.x, a few
> large features were added (new collections, new arrays, named and
> default arguments, etc.). After one (or more, if necessary) big feature
> lands on trunk, one could give it a week or two and then release an
> alpha.

I can't second more Ismael in that way.
I also know that nowadays, it's a sensitive point, and so I will try to
illustrate it with my example.

I'm currently in the process of building a new software in Scala. We are
in early stages, the first prototypes are expected for the end of the
year, and if everything goes well, the base would last for years. So,
it's a nonsense to start with a 2.7 release of Scala to switch to 2.8
perhaps before a 2.8 final. That's a known fact of us that the 2.8
branch is in heavy development, and is expected subjected to fairly big
API modifications until feature freeze of the beta release. But as I
said, I would be a real lost of time to start with a 2.7 scala base to
migrate everything in a few weeks.

I heard the voice of other projects that are lead to the same choice
than us, for example because they are so big that they have to know with
a rather good ahead of time what will have to change in the swith to
2.8, and again other projects that are the basis of so many other ones
that it's almost a requirement for them to be bleeding edge (for ex.
testing and building frameworks)

On the other hand, their is almost daily breaking changes on 2.8. It's
somehow good - things are moving on.
But that make almost impossible to have a common ground to try and
discuss thing between Scalas user and projects that make the choice to
go and try 2.8. We really lake some coordination point - even if the
matching build is known to not be feature complete, and will eventually
change. And we can't wait one or two other months for a beta (in my
case, because one month may be the difference between success and
bankruptcy).

As Ijuma said, it's exactly what alpha are for, especially in project
upgrade with disruptive changes and a really really long timeframe,
exactly what Scala 2.8 is (we are talking about months since the new
collection merge, what was one of the major breaking change awaited for
2.8). Again, we do know that these alphas will evolves, api will break,
eventually. But it let the one of us that really need to go with 2.8 a
better place than the raw snapshot.

All that is said in a really good will, and is in no way here to blame
EPFL. So, I hope it will be taken as a constructive feedback.

--
Francois Armand

>>>>> "Francois" == Francois writes:

Francois> On the other hand, their is almost daily breaking changes on
Francois> 2.8. It's somehow good - things are moving on. But that make
Francois> almost impossible to have a common ground to try and discuss
Francois> thing between Scalas user and projects that make the choice
Francois> to go and try 2.8. We really lake some coordination point -
Francois> even if the matching build is known to not be feature
Francois> complete, and will eventually change.

(replying on scala instead of scala-internals since this information
may be broadly useful)

fwiw, r18687-20090910 seems to be a "good" nightly; I've been using it
for two weeks now with success, and my impression from IRC is that
others are using it too. There are versions of sbt, ScalaTest, and
ScalaCheck (dunno about specs) that all seem to work with it.

and for now, there is no newer "good" nightly (recent string and array
changes, from r18685 on, have broken too many things, despite all the
tests passing; the dust has yet to settle)

as always, caveat emptor

Ismael Juma wrote:
> Hi Toni,
>
> On Fri, 2009-09-25 at 13:02 +0200, Antonio Cunei wrote:
>> * If the community needs preliminary 2.8 releases that are known to be good
>> enough for general testing, and to assist people with migrating to the new
>> code base, then what you really want is a beta release.
>
> The community seems to want something that is closer to an alpha release.
> [...] For example, in 2.8.x, a few
> large features were added (new collections, new arrays, named and
> default arguments, etc.). After one (or more, if necessary) big feature
> lands on trunk, one could give it a week or two and then release an
> alpha.

Francois wrote:
> We really lake some coordination point - even if the matching build is known to not be feature complete, and will eventually change.[...]

Ismael, Francois, thank you for your comments.

I understand that people grew concerned on this occasion by seeing new
stuff landing in trunk without having a reference point that they can agree
on. My hope is that most of these concerns be addressed by the release of
our first beta, which is now imminent.

We are actually taking a bold step by releasing a beta version at this
time: we even debated in the group whether to call it an alpha, or a
technology preview. You would be misled to think that we want to release a
polished version: our intention here is exactly giving the community a tool
to work on, and which is in an acceptable state. So the sentiment is
common: the community wants preliminary releases, and we are doing our best
right now to fulfill that need.

What we would have a hard time, however, is deciding on what to tag as
alphas. Development on our code base is too frantic, and the code is too
unstable. Even I personally do not know at any time whether any of my
colleagues are going to commit stuff in the next five minutes. We commit
code even during the weekly meetings, literally. We receive external
commits all the time. My own main source of information about what is going
on is the commit log.

Tagging snapshots as alphas would be a blind shot for us most of the times.
I am not sure a sequence of such releases would carry any significant
advantage over the regular stream of nightlies, except that such alphas
would last for longer; nightly releases currently vanish after about three
weeks.

What we could do, if that may be of help to the community, is setting up a
further stream of trunk builds that have a longer shelf life. For instance,
we could have a stream of "Bi-Weekly" releases, or "Monthly" releases, that
keep being available for five or six months, for example.

Because of the reasons I described above, however, those will still be
arbitrarily selected by the system among the nightly builds that pass the
testing suite. This still is our best criterion for stability during times
of heavy development, I am afraid. Nonetheless, referring to a set monthly
build is probably better than referring to a nightly build that may
disappear at any moment. Please let us know if that would be a possible
solution; if so, I will look into setting the system up.

I fully agree on the other hand that our testing suite needs more work, and
your hope that the situation will improve over time. We can only reiterate
our call for help on this matter: I am always happy to assist anyone who
wants to help us concretely with testing.

The issue is slightly different for Maven users. From Seth's explanation, I
understand that the nightly snapshots in scala-tools.org are a moving
target, and that old snapshots cannot be accessed. Here at EPFL we have no
control over the scala-tools repository or its inner working, so we can't
do anything about this issue; Josh however mentioned that he will modify
the Maven integration script to work around that, and enable access to
older snapshots. That should hopefully help.

If we go for the slow-moving biweekly or monthly stream of builds, in
addition, the same could be set up on scala-tools as well. I will contact
Josh in this case to see how that can be arranged.

Please let us know if that would work for you.
Toni

On Fri, Sep 25, 2009 at 3:56 PM, Seth Tisue wrote:
> and for now, there is no newer "good" nightly (recent string and array
> changes, from r18685 on, have broken too many things, despite all the
> tests passing; the dust has yet to settle)

This is a bit of an exaggeration ... I'm running the Scala IDE off
trunk quite happily.

Which tickets are causing you particular trouble right now?

Cheers,

Miles

>>>>> "Miles" == Miles Sabin writes:

Miles> Which tickets are causing you particular trouble right now?

#2360
this doesn't work anymore:
"foo".map(x => 3)

#2368
this doesn't work anymore:
(a: Array[Int]) => { a(0) += 1 }

#2369
this doesn't work anymore:
util.Sorting.stableSort(1 to 10,(_:Int) => 1).apply(0)

#2370
this doesn't work anymore:
List(1).sortWith(_ < _)

>> and for now, there is no newer "good" nightly (recent string and
>> array changes, from r18685 on, have broken too many things, despite
>> all the tests passing; the dust has yet to settle)

Miles> This is a bit of an exaggeration ... I'm running the Scala IDE
Miles> off trunk quite happily.

I'm glad all is well in your part of the world. But the tickets above
are all very simple examples involving basic functionality. I'll stick
with 2.8.0-r18678-20090910 for now.

On Fri, Sep 25, 2009 at 4:26 PM, Seth Tisue wrote:
>>>>>> "Miles" == Miles Sabin writes:
>
>  Miles> Which tickets are causing you particular trouble right now?
>
> #2360
> this doesn't work anymore:
> "foo".map(x => 3)
>
> #2368
> this doesn't work anymore:
> (a: Array[Int]) => { a(0) += 1 }
>
> #2369
> this doesn't work anymore:
> util.Sorting.stableSort(1 to 10,(_:Int) => 1).apply(0)
>
> #2370
> this doesn't work anymore:
> List(1).sortWith(_ < _)
>
>  >> and for now, there is no newer "good" nightly (recent string and
>  >> array changes, from r18685 on, have broken too many things, despite
>  >> all the tests passing; the dust has yet to settle)
>
>  Miles> This is a bit of an exaggeration ... I'm running the Scala IDE
>  Miles> off trunk quite happily.
>
> I'm glad all is well in your part of the world.  But the tickets above
> are all very simple examples involving basic functionality.  I'll stick
> with 2.8.0-r18678-20090910 for now.

The last two of these appear to be fixed on trunk.

The first two have trivial workarounds,

"foo".toArray.map(x => 3)

(a: Array[Int]) => { a(0) = a(0) + 1 }

I find it hard to believe that that's too much for you to cope with.

Cheers,

Miles

On Fri, Sep 25, 2009 at 5:37 PM, Miles Sabin wrote:
> On Fri, Sep 25, 2009 at 4:26 PM, Seth Tisue wrote:
>>>>>>> "Miles" == Miles Sabin writes:
>>
>>  Miles> Which tickets are causing you particular trouble right now?
>>
>> #2360
>> this doesn't work anymore:
>> "foo".map(x => 3)
>>
>> #2368
>> this doesn't work anymore:
>> (a: Array[Int]) => { a(0) += 1 }
>>
>> #2369
>> this doesn't work anymore:
>> util.Sorting.stableSort(1 to 10,(_:Int) => 1).apply(0)
>>
>> #2370
>> this doesn't work anymore:
>> List(1).sortWith(_ < _)
>>
>>  >> and for now, there is no newer "good" nightly (recent string and
>>  >> array changes, from r18685 on, have broken too many things, despite
>>  >> all the tests passing; the dust has yet to settle)
>>
>>  Miles> This is a bit of an exaggeration ... I'm running the Scala IDE
>>  Miles> off trunk quite happily.
>>
>> I'm glad all is well in your part of the world.  But the tickets above
>> are all very simple examples involving basic functionality.  I'll stick
>> with 2.8.0-r18678-20090910 for now.
>
> The last two of these appear to be fixed on trunk.
>
> The first two have trivial workarounds,
>
>  "foo".toArray.map(x => 3)
>
>  (a: Array[Int]) => { a(0) = a(0) + 1 }
>
> I find it hard to believe that that's too much for you to cope with.

In fact, I am happy that things are tried quickly against trunk. I'll
hopefully get around to fixing the remaining two tickets soon.
I also hope that we are mostly done with breaking changes by now.
There's still the issue of equality to be resolved, and I will check
in a collection refactoring later today. But after that it should be
much smoother sailing. Anyway thanks for sticking it out with trunk,
and reporting back!

Cheers

>>>>> "Miles" == Miles Sabin writes:

Miles> I find it hard to believe that that's too much for you to cope
Miles> with.

So sarcastic! I've sent a longer reply to this to you privately.

If there are others who have found the post 20090910 nightlies usable
and want to recommend them to others, maybe they'll speak up. My own
experience has been different. Anyway, my point was not so much to call
other nightlies bad, as to call 20090910 good -- in the hope doing so
might help someone.

On Fri, Sep 25, 2009 at 5:12 PM, Seth Tisue wrote:
>>>>>> "Miles" == Miles Sabin writes:
>
>  Miles> I find it hard to believe that that's too much for you to cope
>  Miles> with.
>
> So sarcastic!  I've sent a longer reply to this to you privately.
>
> If there are others who have found the post 20090910 nightlies usable
> and want to recommend them to others, maybe they'll speak up.  My own
> experience has been different.  Anyway, my point was not so much to call
> other nightlies bad, as to call 20090910 good -- in the hope doing so
> might help someone.

No sarcasm ...

I'm genuinely baffled that so many people seem to be expecting to have
EPFL hold their hands for them.

The community needs to either roll up it's sleeves and get on with it,
or be prepared to offer more resources (without strings attached) to
enable the work that we all agree needs to be done.

Cheers,

Miles

On Fri, 2009-09-25 at 17:32 +0100, Miles Sabin wrote:
> I'm genuinely baffled that so many people seem to be expecting to have
> EPFL hold their hands for them.

Even though that may be true, I am surprised why you are directing this
at Seth. Seth has been trying trunk builds regularly and has filed many
tickets (easily seen in Trac's timeline) and I haven't seen him complain
much.

In this particular case, he was simply recommending a nightly that
worked for him along with the usual dependencies. That sounds like a
good thing to me.

It's understandable that users would like to avoid builds that have bugs
that affect a lot of code (even if they have simple workarounds) if
these bugs have already been reported and will be fixed soon.

Personally, I thank Seth for doing spending the time to find and report
bugs after big changes. :)

Best,
Ismael

On Fri, Sep 25, 2009 at 7:32 PM, Ismael Juma wrote:
> On Fri, 2009-09-25 at 17:32 +0100, Miles Sabin wrote:
>> I'm genuinely baffled that so many people seem to be expecting to have
>> EPFL hold their hands for them.
>
> Even though that may be true, I am surprised why you are directing this
> at Seth. Seth has been trying trunk builds regularly and has filed many
> tickets (easily seen in Trac's timeline) and I haven't seen him complain
> much.
>
> In this particular case, he was simply recommending a nightly that
> worked for him along with the usual dependencies. That sounds like a
> good thing to me.
>
> It's understandable that users would like to avoid builds that have bugs
> that affect a lot of code (even if they have simple workarounds) if
> these bugs have already been reported and will be fixed soon.
>
> Personally, I thank Seth for doing spending the time to find and report
> bugs after big changes. :)
>
As I wrote before, I agree very much. -- Martin

On 09/25/2009 04:02 AM, Antonio Cunei wrote:
> The fact that the community is eager for code to be available for
> porting to won't change the fact that the code in trunk is exactly
> what it is: development code. The feedback we gather from users who
> try trunk is invaluable, but it not production code, nor code in which
> any particular feature is supposed to be complete. "Better" means
> beta: you need to wait a few more weeks.

I'd like to just throw this out in -debate to hopefully stimulate
discussion; please don't take it as my prescription for how the Scala
project ought to work:

Having multiple parallel streams of development all targeted at a single
big release is pretty common in larger commercial software projects.
One way we make it tractable is to plan for explicit milestone releases,
each of which integrates functionality that is ready for integration
tests and unlikely to break other features, but that is not necessarily
expected to be alpha quality yet. Changes should be assigned to
milestone slots based on their size/complexity/difficulty and a rough
idea of their dependencies--changes that more likely to impact other
changes (or simply needed by them) must be slotted into earlier milestones.

It's not necessary for each milestone to have its own branch, but it's
important for all the feature/module owners to have a milestone
deadline, e.g. if I know my feature is targeted for M4, and if it misses
that date, it's probably not going into the release.

Here's how I've done it in the past, with a fair degree of success, on a
moderately large (~750kloc) Java codebase.

(or just tell everyone to keep their awesome
experimentation the hell out of trunk)

M0 progress:
Make the major structural/architectural changes that are important,
don't necessarily change functionality, but will make our lives a living
hell if we do them later in the project (major
platform/library/dependency version changes, reorganizing modules...)

M0 tag:
Sanity check, make sure everyone on the team agrees that the project
platform/structure/architecture/library versions will work for the
features they're responsible for.

M1 progress:
The most complex/important/depended-on functionality for this release
really needs to come in here. Generally speaking, in each milestone,
one or more changes are now ready to integrate, merged/committed to the
release branch (or trunk), integration problems are cleaned up,
functional tests *for features scheduled for this milestone* mostly pass.

M1 tag:
M1 features are ready for review, initial testing, criticism etc.

M2..n: (repeat)

Alpha:
All the major refactorings, bug fixes and features that are intended to
ship in this release are integrated, developer-tested and ready for
wider QA, but there are still plenty of known bugs and cut corners. Any
change that was scheduled for a milestone but has yet to attain alpha
quality is not going in the release, or the alpha can be postponed (and
another milestone explicitly added) for changes that are deemed
important enough to slip the release.

Beta:
Basically what you'd expect. All changes integrated, no known bugs that
don't have known workarounds...

At my last job we also had sub-milestone tags we called M1a, M1b etc.
When the developers honestly believed the M1 functionality was ready
we'd tag M1a, then QA would laugh at us and we'd ship zero (*cough*) or
more subsequent sub-milestones roughly once a week until QA signed off
on the final M1x and we'd finally move on to the next milestone.

-0xe1a

Hi Toni,

Thanks for listening and for being open to changes that would make
things easier for us users. Comments below.

On Fri, 2009-09-25 at 16:54 +0200, Antonio Cunei wrote:
> I understand that people grew concerned on this occasion by seeing new
> stuff landing in trunk without having a reference point that they can agree
> on. My hope is that most of these concerns be addressed by the release of
> our first beta, which is now imminent.

Looking forward to that. :)

> So the sentiment is
> common: the community wants preliminary releases, and we are doing our best
> right now to fulfill that need.

Thanks, it's appreciated.

> What we would have a hard time, however, is deciding on what to tag as
> alphas. Development on our code base is too frantic, and the code is too
> unstable. Even I personally do not know at any time whether any of my
> colleagues are going to commit stuff in the next five minutes.

I can see how this would make things difficult. However, does it have to
be this way? Could we make development less frantic by improving the
communication between the various parties involved? I was under the
impression that the weekly meetings by the Scala team were used to
discuss plans and the like. It seems to me that a quick status update
and near future merge plans could go a long way.

I believe that some co-ordination and structure would actually reduce
the workload of the committers. For example, it's much easier to fix
issues and regressions that are reported soon after the code has been
committed than many months later. Regular alpha releases would help with
that. Coordinating large commits so that they don't all go in at the
same time would make it easier to track regressions, saving time. And so
on.

> We commit code even during the weekly meetings, literally. We receive external
> commits all the time. My own main source of information about what is going
> on is the commit log.

I check it on a daily basis (or more) myself.

> Tagging snapshots as alphas would be a blind shot for us most of the times.

>From watching the mailing list, I am unsure if this is really true. It
has happened many times that Martin and others have described the status
of a given feature and parts that were still missing or not working
properly (from a high-level perspective). This makes sense, since one
would expect someone developing a feature to have a better idea of its
status than someone just reading the commit logs.

> Because of the reasons I described above, however, those will still be
> arbitrarily selected by the system among the nightly builds that pass the
> testing suite. This still is our best criterion for stability during times
> of heavy development, I am afraid. Nonetheless, referring to a set monthly
> build is probably better than referring to a nightly build that may
> disappear at any moment. Please let us know if that would be a possible
> solution; if so, I will look into setting the system up.

I think this would be useful. Some human input and judgment would be
even better. To give a concrete (but hypothetical) example, if there was
a monthly build scheduled for a few days back and the big array commit
was due, it would be good if either the build was cancelled/delayed or
the array commit delayed. I don't think this is impossible to do.

> I fully agree on the other hand that our testing suite needs more work, and
> your hope that the situation will improve over time. We can only reiterate
> our call for help on this matter: I am always happy to assist anyone who
> wants to help us concretely with testing.

Indeed. Just to be clear, I did not mean to criticise, just to point out
what the current situation is. I believe that the situation is improving
steadily and it's already much better than last year at the same time,
for example.

> Please let us know if that would work for you.

I think both suggestions would help and they would be even better with
the slight addition I suggested (some human input to the regular
snapshots).

Thanks for listening and looking forward to that beta. :)

Best,
Ismael

Ismael Juma wrote:
> I think both suggestions would help and they would be even better with
> the slight addition I suggested (some human input to the regular
> snapshots).
>
> Thanks for listening and looking forward to that beta. :)
>
> Best,
> Ismael
>

Ismael, All,

We had a meeting today and we discussed this matter at some length. In
terms of human input, we feel that we would not be able to pick ourselves
specific snapshots for release. There are too many factors: stability of
the code, features that are available at a given time and their degree of
development, compatibility with existing software, and so on.

That doesn't mean, however, that the community is not able to select a
revision that seems to be better than others on our behalf: for instance
someone recently noticed that a certain revision was working well, and
posted a comment to that effect.

So, what we are considering doing here at EPFL is the following: first of
all, we make the nightly releases much longer-lived, for instance three months.

Then we set up a rating system, similar to what is showed on the page
below, which lists the nightly builds of the IntelliJ plugin (not our
project). The combination of user-driven ratings and long life should allow
people to focus on specific snapshots that work for them:
http://www.jetbrains.net/confluence/display/SCA/Scala+Plugin+Nightly+Builds

In addition, optionally, every month or so we pick a recent nightly that
received a high user score, and push it to a list of "unstable" releases.
The unstable releases are then propagated to the scala-tools repository, in
addition to the fast-moving nightlies, and will remain available for a much
longer timespan, say six to eight months at least.

That is the general idea. So we ask for feedback from the community at this
stage: would this solution address your needs?
Toni

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

Antonio> Then we set up a rating system, similar to what is showed on
Antonio> the page below, which lists the nightly builds of the IntelliJ
Antonio> plugin (not our project). The combination of user-driven
Antonio> ratings and long life should allow people to focus on specific
Antonio> snapshots that work for them:
Antonio> http://www.jetbrains.net/confluence/display/SCA/Scala+Plugin+Nightly+Builds

Having a central page to collect information about the nightlies is a
great idea. But I think the need is for actual comments, not so much
for star ratings.

The issue with the nightlies is not that some are usable and some are
unusable. Unusable nightlies are pretty rare. (Periods of major
upheaval like the recent one with strings and arrays don't happen that
often.)

To decide whether (and how) to use a particular nightly, I need
specific information on:
- compatibility
- particular changes and regressions
This information can't be compressed into a star rating.

Changes & regressions: if I could leave comments on a nightly, I could
leave a warnings like "Arrays are no longer Seqs as of this nightly,
look out for widespread breakage", "if you use actors watch out for bug
#1234", or (on a later nightly) "this nightly fixes bug #1234, actors
are usable again". Information like this is of course available on the
Trac timeline, but only to people are who dedicated about following it.
A central location for leaving comments about nightlies would allow
users to collaborate on digesting the voluminous raw information in Trac
and condensing it into usable form.

Compatibility: I mean compatibility with third party tools like sbt,
ScalaTest, ScalaCheck, Specs, the NetBeans plugin, the IDEA plugin, and
so on. Real projects tends to use some combination of several of these.
In the absence of milestone builds, figuring out how to get one's
particular toolset working with some particular nightly, or whether it's
even possible to do so (often it's not), is complicated and difficult.
Once someone succeeds, it would be great if there were a central place
where they could record their experience. (Currently the information is
spread across multiple communication channels. To know what's going on
you have to subscribe to a bunch of mailing lists, chat up the tool
authors on IRC, etc.)

To have a central place to record this information, I'm not sure any
sort of custom system is even needed. An ordinary wiki page, editable
by anyone, seems to me like it would be adequate.

Shall I start a page on http://scala.sygneca.com/ ?

Antonio> In addition, optionally, every month or so we pick a recent
Antonio> nightly that received a high user score, and push it to a list
Antonio> of "unstable" releases. The unstable releases are then
Antonio> propagated to the scala-tools repository, in addition to the
Antonio> fast-moving nightlies, and will remain available for a much
Antonio> longer timespan, say six to eight months at least.

Sounds great. But I suggest that the primary criterion for promotion
should be compatibility with popular build tools, testing frameworks,
and IDE plugins.

On Fri, 2009-10-23 at 10:35 -0500, Seth Tisue wrote:
> >>>>> "Antonio" == Antonio Cunei writes:
>
> Antonio> Then we set up a rating system, similar to what is showed on
> Antonio> the page below, which lists the nightly builds of the IntelliJ
> Antonio> plugin (not our project). The combination of user-driven
> Antonio> ratings and long life should allow people to focus on specific
> Antonio> snapshots that work for them:
> Antonio> http://www.jetbrains.net/confluence/display/SCA/Scala+Plugin+Nightly+Builds
>
> Having a central page to collect information about the nightlies is a
> great idea. But I think the need is for actual comments, not so much
> for star ratings.

I had forgotten to reply about this. I agree that comments are also
useful, but so are ratings. See what Fedora does here, for example:

https://admin.fedoraproject.org/updates/F11/FEDORA-2009-10713?_csrf_toke...

You can comment and give a rating and there's a "Karma" field at the top
that summarises it.

Best,
Ismael