RC2 to arrive soon

On Tue, Apr 27, 2010 at 8:34 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Adriaan and I think we might have fixed the last remaining problem reported by David. Our assumption is that it's the same as ticket #3349, which we could fix. This means we are probably ready to roll an RC2 at the end of this week unless something else gets reported.

So, I'd like to stabilize trunk by tonight, which means that afterwards only uncontroversial bugfixes should go in.
If anyone thinks that's too soon because they want to do some major change before that, please let me know now.

Over the next three days we will only fix uncontroversial tickets and (with priority) build failures of major tools against the nightly. If that progresses smoothly we plan to come out with an RC2 by the end of the week.

Martin,

Did you fix https://lampsvn.epfl.ch/trac/scala/ticket/3362

It's blocking specs so we haven't had a chance to test Lift.

Thanks,

David
 

Cheers

 -- Martin

--
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 Tue, Apr 27, 2010 at 05:34:35PM +0200, martin odersky wrote:
> So, I'd like to stabilize trunk by tonight, which means that
> afterwards only uncontroversial bugfixes should go in.

Can I commit that improved error message patch I asked about? I'd like
to get that in, or some variation of it.

On Tue, Apr 27, 2010 at 5:59 PM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Apr 27, 2010 at 05:34:35PM +0200, martin odersky wrote:
> So, I'd like to stabilize trunk by tonight, which means that
> afterwards only uncontroversial bugfixes should go in.

Can I commit that improved error message patch I asked about? I'd like
to get that in, or some variation of it.

By when can you do it? (Almost) anything goes as long as it's today. If not we can also wait a day before stabilizing trunk.

Cheers

 -- Martin

On Tue, Apr 27, 2010 at 5:49 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Tue, Apr 27, 2010 at 8:34 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Adriaan and I think we might have fixed the last remaining problem reported by David. Our assumption is that it's the same as ticket #3349, which we could fix. This means we are probably ready to roll an RC2 at the end of this week unless something else gets reported.

So, I'd like to stabilize trunk by tonight, which means that afterwards only uncontroversial bugfixes should go in.
If anyone thinks that's too soon because they want to do some major change before that, please let me know now.

Over the next three days we will only fix uncontroversial tickets and (with priority) build failures of major tools against the nightly. If that progresses smoothly we plan to come out with an RC2 by the end of the week.

Martin,

Did you fix https://lampsvn.epfl.ch/trac/scala/ticket/3362

It's blocking specs so we haven't had a chance to test Lift.

I'm surprised. The code in the example is clearly incorrect,

  abstract class Matcher[-T] {
    def apply(t: =>T) = t
  }

The compiler correctly reports that contravariant T is used covariantly in apply's type (=>T)T. The problem is that the compiler crashes afterwards, and this behavior is of course a ticket to fix. But in any case this specs code would not compile even after the ticket was fixed. So I fail to see how the ticket could be blocking specs.

Cheers

 -- Martin

 

I just broke the build with a test file (a check file containing object addresses...) How dumb.. I'll fix it ASAP.

On Tue, Apr 27, 2010 at 6:07 PM, martin odersky <martin.odersky@epfl.ch> wrote:

On Tue, Apr 27, 2010 at 5:49 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Tue, Apr 27, 2010 at 8:34 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Adriaan and I think we might have fixed the last remaining problem reported by David. Our assumption is that it's the same as ticket #3349, which we could fix. This means we are probably ready to roll an RC2 at the end of this week unless something else gets reported.

So, I'd like to stabilize trunk by tonight, which means that afterwards only uncontroversial bugfixes should go in.
If anyone thinks that's too soon because they want to do some major change before that, please let me know now.

Over the next three days we will only fix uncontroversial tickets and (with priority) build failures of major tools against the nightly. If that progresses smoothly we plan to come out with an RC2 by the end of the week.

Martin,

Did you fix https://lampsvn.epfl.ch/trac/scala/ticket/3362

It's blocking specs so we haven't had a chance to test Lift.

I'm surprised. The code in the example is clearly incorrect,

  abstract class Matcher[-T] {
    def apply(t: =>T) = t
  }

The compiler correctly reports that contravariant T is used covariantly in apply's type (=>T)T. The problem is that the compiler crashes afterwards, and this behavior is of course a ticket to fix. But in any case this specs code would not compile even after the ticket was fixed. So I fail to see how the ticket could be blocking specs.

Cheers

 -- Martin

 

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Tue, Apr 27, 2010 at 6:07 PM, martin odersky <martin.odersky@epfl.ch> wrote:

On Tue, Apr 27, 2010 at 5:49 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Tue, Apr 27, 2010 at 8:34 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Adriaan and I think we might have fixed the last remaining problem reported by David. Our assumption is that it's the same as ticket #3349, which we could fix. This means we are probably ready to roll an RC2 at the end of this week unless something else gets reported.

So, I'd like to stabilize trunk by tonight, which means that afterwards only uncontroversial bugfixes should go in.
If anyone thinks that's too soon because they want to do some major change before that, please let me know now.

Over the next three days we will only fix uncontroversial tickets and (with priority) build failures of major tools against the nightly. If that progresses smoothly we plan to come out with an RC2 by the end of the week.

Martin,

Did you fix https://lampsvn.epfl.ch/trac/scala/ticket/3362

It's blocking specs so we haven't had a chance to test Lift.

I'm surprised. The code in the example is clearly incorrect,

  abstract class Matcher[-T] {
    def apply(t: =>T) = t
  }

The compiler correctly reports that contravariant T is used covariantly in apply's type (=>T)T. The problem is that the compiler crashes afterwards, and this behavior is of course a ticket to fix. But in any case this specs code would not compile even after the ticket was fixed. So I fail to see how the ticket could be blocking specs.

Cheers

 -- Martin

I was misled by the last comment to the ticket. In fact the compiler crashes even if the variance error is corrected. So this IS a real blocker. I'm on it.

Cheers
 
 -- Martin

I have half-good news: #3362 is closed now. But there's still an error in specs. The new behavior is that the compiler will just give the previous crash message as a regular error message (in fact the error was simply that the phase superAccessors which detected the error was not set up for normal error reporting). And there's indeed an error in specs. In the fragment

def calcBar: Class[_] = classOf[Baz]
new Exp(calcBar).must(be(classOf[Baz]))

the type of calcBar in the 2nd line gets inferred to be Class[$1], for some fixed type $1.
It then expects a Class[$1] for the `must` argument, which fails with the error message given.
To avoid the error you must give an explicit type parameter to `Exp`. For instance the following works:

  new Exp[Class[_]](calcBar).must(be(classOf[Baz]))

I realize it's inconvenient but that's how existential types work. I suspect that Java wildcards would be no different.

Cheers

 -- Martin

On Tue, Apr 27, 2010 at 6:07 PM, martin odersky <martin.odersky@epfl.ch> wrote:

On Tue, Apr 27, 2010 at 5:49 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Tue, Apr 27, 2010 at 8:34 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Adriaan and I think we might have fixed the last remaining problem reported by David. Our assumption is that it's the same as ticket #3349, which we could fix. This means we are probably ready to roll an RC2 at the end of this week unless something else gets reported.

So, I'd like to stabilize trunk by tonight, which means that afterwards only uncontroversial bugfixes should go in.
If anyone thinks that's too soon because they want to do some major change before that, please let me know now.

Over the next three days we will only fix uncontroversial tickets and (with priority) build failures of major tools against the nightly. If that progresses smoothly we plan to come out with an RC2 by the end of the week.

Martin,

Did you fix https://lampsvn.epfl.ch/trac/scala/ticket/3362

It's blocking specs so we haven't had a chance to test Lift.

I'm surprised. The code in the example is clearly incorrect,

  abstract class Matcher[-T] {
    def apply(t: =>T) = t
  }

The compiler correctly reports that contravariant T is used covariantly in apply's type (=>T)T. The problem is that the compiler crashes afterwards, and this behavior is of course a ticket to fix. But in any case this specs code would not compile even after the ticket was fixed. So I fail to see how the ticket could be blocking specs.

Cheers

 -- Martin

I was misled by the last comment to the ticket. In fact the compiler crashes even if the variance error is corrected. So this IS a real blocker. I'm on it.

Cheers
 
 -- Martin

On Tue, Apr 27, 2010 at 9:26 PM, martin odersky <martin.odersky@epfl.ch> wrote:

I have half-good news: #3362 is closed now. But there's still an error in specs. The new behavior is that the compiler will just give the previous crash message as a regular error message (in fact the error was simply that the phase superAccessors which detected the error was not set up for normal error reporting). And there's indeed an error in specs. In the fragment

So with that and Paul's recent commit I think we are ready to stabilize trunk, for a likely RC2 on Friday.

Cheers

 -- Martin

 

def calcBar: Class[_] = classOf[Baz]
new Exp(calcBar).must(be(classOf[Baz]))

the type of calcBar in the 2nd line gets inferred to be Class[$1], for some fixed type $1.
It then expects a Class[$1] for the `must` argument, which fails with the error message given.
To avoid the error you must give an explicit type parameter to `Exp`. For instance the following works:

  new Exp[Class[_]](calcBar).must(be(classOf[Baz]))

I realize it's inconvenient but that's how existential types work. I suspect that Java wildcards would be no different.

Cheers

 -- Martin

On Tue, Apr 27, 2010 at 6:07 PM, martin odersky <martin.odersky@epfl.ch> wrote:

On Tue, Apr 27, 2010 at 5:49 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Tue, Apr 27, 2010 at 8:34 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Adriaan and I think we might have fixed the last remaining problem reported by David. Our assumption is that it's the same as ticket #3349, which we could fix. This means we are probably ready to roll an RC2 at the end of this week unless something else gets reported.

So, I'd like to stabilize trunk by tonight, which means that afterwards only uncontroversial bugfixes should go in.
If anyone thinks that's too soon because they want to do some major change before that, please let me know now.

Over the next three days we will only fix uncontroversial tickets and (with priority) build failures of major tools against the nightly. If that progresses smoothly we plan to come out with an RC2 by the end of the week.

Martin,

Did you fix https://lampsvn.epfl.ch/trac/scala/ticket/3362

It's blocking specs so we haven't had a chance to test Lift.

I'm surprised. The code in the example is clearly incorrect,

  abstract class Matcher[-T] {
    def apply(t: =>T) = t
  }

The compiler correctly reports that contravariant T is used covariantly in apply's type (=>T)T. The problem is that the compiler crashes afterwards, and this behavior is of course a ticket to fix. But in any case this specs code would not compile even after the ticket was fixed. So I fail to see how the ticket could be blocking specs.

Cheers

 -- Martin

I was misled by the last comment to the ticket. In fact the compiler crashes even if the variance error is corrected. So this IS a real blocker. I'm on it.

Cheers
 
 -- Martin

Hi all,
I'm still waiting for the nightly for r21709 to be produced (I just can see r21699 on the nightly page at the moment) and I'll deploy a new version of specs.
If the build is already ready somewhere else please tell me and I'll do it right away.
Thanks,
Eric.
 ----------------------------------------------
Eric TORREBORRE
T +61 411 707 402
E etorreborre@yahoo.com
B http://etorreborre.blogspot.com
P http://specs.googlecode.com
----------------------------------------------

De : martin odersky <martin.odersky@epfl.ch>
À : David Pollak <feeder.of.the.bears@gmail.com>
Cc : scala-internals@listes.epfl.ch
Envoyé le : Mer 28 avril 2010, 5 h 26 min 32 s
Objet : Re: [scala-internals] RC2 to arrive soon

I have half-good news: #3362 is closed now. But there's still an error in specs. The new behavior is that the compiler will just give the previous crash message as a regular error message (in fact the error was simply that the phase superAccessors which detected the error was not set up for normal error reporting). And there's indeed an error in specs. In the fragment

def calcBar: Class[_] = classOf[Baz]
new Exp(calcBar).must(be(classOf[Baz]))

the type of calcBar in the 2nd line gets inferred to be Class[$1], for some fixed type $1.
It then expects a Class[$1] for the `must` argument, which fails with the error message given.
To avoid the error you must give an explicit type parameter to `Exp`. For instance the following works:

  new Exp[Class[_]](calcBar).must(be(classOf[Baz]))

I realize it's inconvenient but that's how existential types work. I suspect that Java wildcards would be no different.

Cheers

 -- Martin

On Tue, Apr 27, 2010 at 6:07 PM, martin odersky <martin [dot] odersky [at] epfl [dot] ch" target="_blank" href="mailto:martin.odersky@epfl.ch" rel="nofollow">martin.odersky@epfl.ch> wrote:

On Tue, Apr 27, 2010 at 5:49 PM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com" target="_blank" href="mailto:feeder.of.the.bears@gmail.com" rel="nofollow">feeder.of.the.bears@gmail.com> wrote:

On Tue, Apr 27, 2010 at 8:34 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch" target="_blank" href="mailto:martin.odersky@epfl.ch" rel="nofollow">martin.odersky@epfl.ch> wrote:

Adriaan and I think we might have fixed the last remaining problem reported by David. Our assumption is that it's the same as ticket #3349, which we could fix. This means we are probably ready to roll an RC2 at the end of this week unless something else gets reported.

So, I'd like to stabilize trunk by tonight, which means that afterwards only uncontroversial bugfixes should go in.
If anyone thinks that's too soon because they want to do some major change before that, please let me know now.

Over the next three days we will only fix uncontroversial tickets and (with priority) build failures of major tools against the nightly. If that progresses smoothly we plan to come out with an RC2 by the end of the week.

Martin,

Did you fix https://lampsvn.epfl.ch/trac/scala/ticket/3362

It's blocking specs so we haven't had a chance to test Lift.

I'm surprised. The code in the example is clearly incorrect,

  abstract class Matcher[-T] {
    def apply(t: =>T) = t
  }

The compiler correctly reports that contravariant T is used covariantly in apply's type (=>T)T. The problem is that the compiler crashes afterwards, and this behavior is of course a ticket to fix. But in any case this specs code would not compile even after the ticket was fixed. So I fail to see how the ticket could be blocking specs.

Cheers

 -- Martin

I was misled by the last comment to the ticket. In fact the compiler crashes even if the variance error is corrected. So this IS a real blocker. I'm on it.

Cheers
 
 -- Martin

I'd like to commit some changes that affect the optimizer (fixing #3357, #3099 and #3191). Only the last one is (semi-)critical, causing a VerifyError when inlining, but given that all tests pass (-opt), it seems safe. Do I have the green light?
iulian

On Tue, Apr 27, 2010 at 6:01 PM, martin odersky <martin.odersky@epfl.ch> wrote:

On Tue, Apr 27, 2010 at 5:59 PM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Apr 27, 2010 at 05:34:35PM +0200, martin odersky wrote:
> So, I'd like to stabilize trunk by tonight, which means that
> afterwards only uncontroversial bugfixes should go in.

Can I commit that improved error message patch I asked about? I'd like
to get that in, or some variation of it.

By when can you do it? (Almost) anything goes as long as it's today. If not we can also wait a day before stabilizing trunk.

Cheers

 -- Martin

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Wed, Apr 28, 2010 at 2:06 PM, Iulian Dragos <iulian.dragos@epfl.ch> wrote:

I'd like to commit some changes that affect the optimizer (fixing #3357, #3099 and #3191). Only the last one is (semi-)critical, causing a VerifyError when inlining, but given that all tests pass (-opt), it seems safe. Do I have the green light?

Yes, I think we should be fine for that.

Cheers

 -- Martin
 

iulian

On Tue, Apr 27, 2010 at 6:01 PM, martin odersky <martin.odersky@epfl.ch> wrote:

On Tue, Apr 27, 2010 at 5:59 PM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Apr 27, 2010 at 05:34:35PM +0200, martin odersky wrote:
> So, I'd like to stabilize trunk by tonight, which means that
> afterwards only uncontroversial bugfixes should go in.

Can I commit that improved error message patch I asked about? I'd like
to get that in, or some variation of it.

By when can you do it? (Almost) anything goes as long as it's today. If not we can also wait a day before stabilizing trunk.

Cheers

 -- Martin

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Is this going to affect binary compatibility? If so, I would hold it until RC3, since Specs has already published a binary artifact and they (and anyone else who's published a binary) would have to re-publish.
--j
On Wed, Apr 28, 2010 at 9:54 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Wed, Apr 28, 2010 at 2:06 PM, Iulian Dragos <iulian.dragos@epfl.ch> wrote:

I'd like to commit some changes that affect the optimizer (fixing #3357, #3099 and #3191). Only the last one is (semi-)critical, causing a VerifyError when inlining, but given that all tests pass (-opt), it seems safe. Do I have the green light?

Yes, I think we should be fine for that.

Cheers

 -- Martin
 

iulian

On Tue, Apr 27, 2010 at 6:01 PM, martin odersky <martin.odersky@epfl.ch> wrote:

On Tue, Apr 27, 2010 at 5:59 PM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Apr 27, 2010 at 05:34:35PM +0200, martin odersky wrote:
> So, I'd like to stabilize trunk by tonight, which means that
> afterwards only uncontroversial bugfixes should go in.

Can I commit that improved error message patch I asked about? I'd like
to get that in, or some variation of it.

By when can you do it? (Almost) anything goes as long as it's today. If not we can also wait a day before stabilizing trunk.

Cheers

 -- Martin

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Wed, Apr 28, 2010 at 2:55 PM, Jorge Ortiz wrote:
> Is this going to affect binary compatibility? If so, I would hold it until
> RC3, since Specs has already published a binary artifact and they (and
> anyone else who's published a binary) would have to re-publish.

I don't know if this affects binary compatibility, but I disagree. I'd
expect binaries to be republished once RC2 is out anyway. Otherwise
we're setting a blessed nightly to a higher standard than the actual
RC and that doesn't make sense to me.

Best,
Ismael

On Wed, Apr 28, 2010 at 03:20:43PM +0100, Ismael Juma wrote:
> I don't know if this affects binary compatibility, but I disagree. I'd
> expect binaries to be republished once RC2 is out anyway. Otherwise
> we're setting a blessed nightly to a higher standard than the actual
> RC and that doesn't make sense to me.

Yeah, I was going to point out that if binary compatibility is the goal
we are pretty much shutting down trunk for three days. We don't even
have any tools (that I'm aware of) for indicating whether a particular
source change will impact binary compatibility -- and it can be pretty
subtle to know. In fact it can be impossible to know without analyzing
the bytecode, because a change in the type inferencer can cause the same
code to compile differently.

And that's all leaving aside the unlikelihood of being able to commit
any interesting bugfixes without breaking it. Personally I have no
interest in even trying to program under such constraints.

On Wed, Apr 28, 2010 at 4:55 PM, Paul Phillips <paulp@improving.org> wrote:

On Wed, Apr 28, 2010 at 03:20:43PM +0100, Ismael Juma wrote:
> I don't know if this affects binary compatibility, but I disagree. I'd
> expect binaries to be republished once RC2 is out anyway. Otherwise
> we're setting a blessed nightly to a higher standard than the actual
> RC and that doesn't make sense to me.

Yeah, I was going to point out that if binary compatibility is the goal
we are pretty much shutting down trunk for three days.  We don't even
have any tools (that I'm aware of) for indicating whether a particular
source change will impact binary compatibility -- and it can be pretty
subtle to know.  In fact it can be impossible to know without analyzing
the bytecode, because a change in the type inferencer can cause the same
code to compile differently.

And that's all leaving aside the unlikelihood of being able to commit
any interesting bugfixes without breaking it.  Personally I have no
interest in even trying to program under such constraints.

I agree. The current hold-off phase is for testing only. I propose that everybody syncs on the last nightly, i.e. Hudson nightly-main build

#393939 (Apr 28, 2010 2:01:27 AM)

We will put in effort to keep trunk reasonably stable until the RC2 so that any tests done against that nightly are meaningful. We cannot guarantee binary compatibility; i.e. everything should be built once RC2 is out. For keeping track of binary compatibility changes we'd need more tools than we have available have right now.

Cheers

 -- Martin

On Wed, Apr 28, 2010 at 8:12 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Wed, Apr 28, 2010 at 4:55 PM, Paul Phillips <paulp@improving.org> wrote:

On Wed, Apr 28, 2010 at 03:20:43PM +0100, Ismael Juma wrote:
> I don't know if this affects binary compatibility, but I disagree. I'd
> expect binaries to be republished once RC2 is out anyway. Otherwise
> we're setting a blessed nightly to a higher standard than the actual
> RC and that doesn't make sense to me.

Yeah, I was going to point out that if binary compatibility is the goal
we are pretty much shutting down trunk for three days.  We don't even
have any tools (that I'm aware of) for indicating whether a particular
source change will impact binary compatibility -- and it can be pretty
subtle to know.  In fact it can be impossible to know without analyzing
the bytecode, because a change in the type inferencer can cause the same
code to compile differently.

And that's all leaving aside the unlikelihood of being able to commit
any interesting bugfixes without breaking it.  Personally I have no
interest in even trying to program under such constraints.

I agree. The current hold-off phase is for testing only. I propose that everybody syncs on the last nightly, i.e. Hudson nightly-main build

#393939 (Apr 28, 2010 2:01:27 AM)

We will put in effort to keep trunk reasonably stable until the RC2 so that any tests done against that nightly are meaningful. We cannot guarantee binary compatibility; i.e. everything should be built once RC2 is out. For keeping track of binary compatibility changes we'd need more tools than we have available have right now.

Folks,

I agree that all the ecosystem tools should be rebuilt against RC2 once out.

If there's a patch that absolutely needs to go in, then it should go in, but that should also reset the clock for RC2 slush.  Why?

• Any change to the code that doesn't fix a bug is potential instability.  Yeah, yeah, "there's no way that this could cause problems", but in reality the kind of pre-flight check a code slush offers is violated if code is changed except to fix bugs found during the slush period.
• Having a list of what we know is necessary for RC2 and for final is an important part of this process.  That way we have an idea of what the deltas look like and can get a sense of how long and how much between now and a release.  Tickets #3357, #3099 and #3191 are either on that list or they're not.
  
• We're not the only folks who care about this.  There are prospective Scala users at big companies.  There are folks thinking about investing in Scala-related businesses.  Showing these parties that they can reasonably judge the release is important as Scala becomes a realistic candidate for mainstream adoption.

I'm not suggesting that the process I'm advocating for is easy.  On the other hand, EPFL and the rest of the community has some tremendous talent and skills and I wholeheartedly believe that the changes can be done and that the short term pain will lead to a longer-term gain.

Thanks,

David


 

Cheers

 -- Martin

--
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> Having a list of what we know is necessary for RC2 and for final
David> is an important part of this process. That way we have an idea
David> of what the deltas look like and can get a sense of how long and
David> how much between now and a release.

+1. I have my own list of ticket numbers I care about (a number of them
regressions since 2.7) and I don't know whether I should be calling them
to somebody's attention or not. There are so many open bugs it's easy
for important ones to get lost in the shuffle.

While 2.8 was still a "beta", I wasn't too concerned about being in the
dark about the status of particular bugs. But now that we're at the
"release candidate" stage, with the threat of a final release imminent,
for the community to have no idea which open bugs are planned to be
fixed for 2.8 final and which aren't is too haphazard for a release of
this importance.

I don't speak up about this kind of thing too often as I appreciate that
adding process is burdensome and usually things work out all right
anyway. But I really think this one is important.

The pattern I'm used to see is this:
No resetting clock == milestoneResetting clock == release candidate
Both things are useful and have it's place, but it seems there's some conceptual disagreement underlying the discussion of the process to follow here.
If we are reaching the final format of Scala 2.8.0, the best thing would be to branch off 2.8.0, and produce release candidates (resetting clock). If not, this should be considered just a milestone, and no resetting clock is called for.
IMHO, based on my experience as a FreeBSD committer, a decade ago. One's milleage may vary.
But, anyway, I think it would be better if the basic goal was made clearer.
On Wed, Apr 28, 2010 at 1:11 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Wed, Apr 28, 2010 at 8:12 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Wed, Apr 28, 2010 at 4:55 PM, Paul Phillips <paulp@improving.org> wrote:

On Wed, Apr 28, 2010 at 03:20:43PM +0100, Ismael Juma wrote:
> I don't know if this affects binary compatibility, but I disagree. I'd
> expect binaries to be republished once RC2 is out anyway. Otherwise
> we're setting a blessed nightly to a higher standard than the actual
> RC and that doesn't make sense to me.

Yeah, I was going to point out that if binary compatibility is the goal
we are pretty much shutting down trunk for three days.  We don't even
have any tools (that I'm aware of) for indicating whether a particular
source change will impact binary compatibility -- and it can be pretty
subtle to know.  In fact it can be impossible to know without analyzing
the bytecode, because a change in the type inferencer can cause the same
code to compile differently.

And that's all leaving aside the unlikelihood of being able to commit
any interesting bugfixes without breaking it.  Personally I have no
interest in even trying to program under such constraints.

I agree. The current hold-off phase is for testing only. I propose that everybody syncs on the last nightly, i.e. Hudson nightly-main build

#393939 (Apr 28, 2010 2:01:27 AM)

We will put in effort to keep trunk reasonably stable until the RC2 so that any tests done against that nightly are meaningful. We cannot guarantee binary compatibility; i.e. everything should be built once RC2 is out. For keeping track of binary compatibility changes we'd need more tools than we have available have right now.

Folks,

I agree that all the ecosystem tools should be rebuilt against RC2 once out.

If there's a patch that absolutely needs to go in, then it should go in, but that should also reset the clock for RC2 slush.  Why?

• Any change to the code that doesn't fix a bug is potential instability.  Yeah, yeah, "there's no way that this could cause problems", but in reality the kind of pre-flight check a code slush offers is violated if code is changed except to fix bugs found during the slush period.
• Having a list of what we know is necessary for RC2 and for final is an important part of this process.  That way we have an idea of what the deltas look like and can get a sense of how long and how much between now and a release.  Tickets #3357, #3099 and #3191 are either on that list or they're not.
  
• We're not the only folks who care about this.  There are prospective Scala users at big companies.  There are folks thinking about investing in Scala-related businesses.  Showing these parties that they can reasonably judge the release is important as Scala becomes a realistic candidate for mainstream adoption.

I'm not suggesting that the process I'm advocating for is easy.  On the other hand, EPFL and the rest of the community has some tremendous talent and skills and I wholeheartedly believe that the changes can be done and that the short term pain will lead to a longer-term gain.

Thanks,

David


 

Cheers

 -- Martin

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

--
Daniel C. Sobral

I travel to the future all the time.

On Wed, Apr 28, 2010 at 6:11 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:
 

Folks,

I agree that all the ecosystem tools should be rebuilt against RC2 once out.

If there's a patch that absolutely needs to go in, then it should go in, but that should also reset the clock for RC2 slush.  Why?

At this point I really need to understand what is the reason to have this slush. It is exactly an RC for an RC, why not simplify our lives and call it such? The only difference I see is the 3 days of abstinence, when trunk should not be touched.  

• Having a list of what we know is necessary for RC2 and for final is an important part of this process.  That way we have an idea of what the deltas look like and can get a sense of how long and how much between now and a release.  Tickets #3357, #3099 and #3191 are either on that list or they're not.
  

It is desirable to have such a list, but for the moment we don't. I'm fine with trashing these fixes, I just wish I knew what our release process is, and save half a day of work. 

• We're not the only folks who care about this.  There are prospective Scala users at big companies.  There are folks thinking about investing in Scala-related businesses.  Showing these parties that they can reasonably judge the release is important as Scala becomes a realistic candidate for mainstream adoption.

I'm not suggesting that the process I'm advocating for is easy.  On the other hand, EPFL and the rest of the community has some tremendous talent and skills and I wholeheartedly believe that the changes can be done and that the short term pain will lead to a longer-term gain.

Sounds great, but first we need to agree how we want our release process. Having a list of things to fix for the next release sounds very good, but we need community input on what's important. For instance, voting on preferred issues on Trac.   iulian

Thanks,

David


 

Cheers

 -- Martin

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

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Wed, Apr 28, 2010 at 6:14 PM, Iulian Dragos <iulian.dragos@epfl.ch> wrote:

On Wed, Apr 28, 2010 at 6:11 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:
 

Folks,

I agree that all the ecosystem tools should be rebuilt against RC2 once out.

If there's a patch that absolutely needs to go in, then it should go in, but that should also reset the clock for RC2 slush.  Why?

At this point I really need to understand what is the reason to have this slush. It is exactly an RC for an RC, why not simplify our lives and call it such? The only difference I see is the 3 days of abstinence, when trunk should not be touched.

The reason for code slush is binary incompatibility, which has an unfortunate trickle down effect. If Specs can't compile with RC1, then pretty much the entire Scala ecosystem can't adequately test RC1. If Lift can't compile with RC2, then the entire Lift ecosystem can't adequately test RC2. The three days of abstinence means that at least the major libraries and frameworks (Specs, Lift, etc) can guarantee that they will be able to work with the RC. Once that happens, Scala can release an RC, Specs and Lift can release binaries targeting that RC, and the Scala and Lift ecosystems can actually test the RC with their code.
If there's a commit that breaks Specs or Lift or some other major library or framework, and there isn't enough time between the commit and the RC to address the breakage, then a substantial portion of the Scala ecosystem is left out from testing that RC, which means it's not really a "candidate" for release, unless we're willing to release something that hasn't been thoroughly vetted.

• Having a list of what we know is necessary for RC2 and for final is an important part of this process.  That way we have an idea of what the deltas look like and can get a sense of how long and how much between now and a release.  Tickets #3357, #3099 and #3191 are either on that list or they're not.
  

It is desirable to have such a list, but for the moment we don't. I'm fine with trashing these fixes, I just wish I knew what our release process is, and save half a day of work. 

I don't understand under which scenario this fix would have to be trashed. If it's applied now, great, but that should reset the code slush. If it's not applied, surely it can be saved in a patch file and applied later?

• We're not the only folks who care about this.  There are prospective Scala users at big companies.  There are folks thinking about investing in Scala-related businesses.  Showing these parties that they can reasonably judge the release is important as Scala becomes a realistic candidate for mainstream adoption.

I'm not suggesting that the process I'm advocating for is easy.  On the other hand, EPFL and the rest of the community has some tremendous talent and skills and I wholeheartedly believe that the changes can be done and that the short term pain will lead to a longer-term gain.

Sounds great, but first we need to agree how we want our release process. Having a list of things to fix for the next release sounds very good, but we need community input on what's important. For instance, voting on preferred issues on Trac.  

It's possible to see tickets in Trac sorted by voted:https://lampsvn.epfl.ch/trac/scala/report/9
And tickets in Trac sorted by length of cc list:https://lampsvn.epfl.ch/trac/scala/report/11
Surely some of these are out of scope for 2.8.0, but I think those lists (especially the cc list) give a good sense of what people care about. Perhaps we can encourage people on scala@ to upvote issues they feel strongly about.
--j 

iulian

Thanks,

David


 

Cheers

 -- Martin

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

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Hi Jorge,

If there's a commit that breaks Specs or Lift or some other major library or framework, and there isn't enough time between the commit and the RC to address the breakage, then a substantial portion of the Scala ecosystem is left out from testing that RC, which means it's not really a "candidate" for release, unless we're willing to release something that hasn't been thoroughly vetted.

You are right in principle, but we try to keep the probability of this happening small.
If there's a build bug reported against stable trunk of course the RC will be delayed until this is fixed. The only remaining possibility is that the bug goes undetected until the RC is released because it was introduced by a ticket fix in the stability period. It's a possibility but hopefully an unlikely one. In any case we are talking about RC's here and not finals. There will be no changes to trunk between the last succesful RC and the final.
 
We have to weigh these risks against the productivity loss of not fixing tickets for the slush days. We have obviously different interests in this matter. The Scala core team's primary objective is to have the lowest overhead process that enables them to fix the most tickets in the limited time they have available. The interest of the lift, ScalaTest and specs people is to have a period that's a long as possible where trunk is unchanged before an RC. You cannot have both. Higher process overhead means some tickets will not be fixed that some other people might care about.

The process for the RC2 release I have outlined is intended to be a reasonable compromise that did take the input of the lift community into account. I have discussed it at length with he core team. I think we'll run with it now in the way it was announced.
We can do a postmortem after the final 2.8 release, but for now let's get on with it.

Cheers

 -- Martin

On Thu, Apr 29, 2010 at 1:17 AM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

The reason for code slush is binary incompatibility, which has an unfortunate trickle down effect. If Specs can't compile with RC1, then pretty much the entire Scala ecosystem can't adequately test RC1. If Lift can't compile with RC2, then the entire Lift ecosystem can't adequately test RC2. The three days of abstinence means that at least the major libraries and frameworks (Specs, Lift, etc) can guarantee that they will be able to work with the RC. Once that happens, Scala can release an RC, Specs and Lift can release binaries targeting that RC, and the Scala and Lift ecosystems can actually test the RC with their code.
If there's a commit that breaks Specs or Lift or some other major library or framework, and there isn't enough time between the commit and the RC to address the breakage, then a substantial portion of the Scala ecosystem is left out from testing that RC, which means it's not really a "candidate" for release, unless we're willing to release something that hasn't been thoroughly vetted.

I think we run the risk of infinite regression. We are talking about RCs, not final releases. They are transient, and their role was exactly this: to allow the whole ecosystem to boot, and have a usable release. I don't see the point in blessing RCs with the same characteristics. Are you confident that 3 days are enough for all important players to align? Maybe in a few months, there will be more than 5 projects that need to boot. Do we increase the slush to 5 days or a week? Assume during the slush period scalatest breaks. We will fix it immediately and 'release' another nightly and ask everyone to retest the new slushy nightly. I don't see a fundamental difference between RCs and 'slushes'.  

• Having a list of what we know is necessary for RC2 and for final is an important part of this process.  That way we have an idea of what the deltas look like and can get a sense of how long and how much between now and a release.  Tickets #3357, #3099 and #3191 are either on that list or they're not.
  

It is desirable to have such a list, but for the moment we don't. I'm fine with trashing these fixes, I just wish I knew what our release process is, and save half a day of work. 

I don't understand under which scenario this fix would have to be trashed. If it's applied now, great, but that should reset the code slush. If it's not applied, surely it can be saved in a patch file and applied later?

Surely. In the heat of the moment, I exaggerated. I can keep any number of branches on github, and merge them at some later time. What I'm more worried is that I could have used my time differently, that 2.8.1 is not yet in sight, and the feeling that the rules of the game change during the game.  

• We're not the only folks who care about this.  There are prospective Scala users at big companies.  There are folks thinking about investing in Scala-related businesses.  Showing these parties that they can reasonably judge the release is important as Scala becomes a realistic candidate for mainstream adoption.

I'm not suggesting that the process I'm advocating for is easy.  On the other hand, EPFL and the rest of the community has some tremendous talent and skills and I wholeheartedly believe that the changes can be done and that the short term pain will lead to a longer-term gain.

Sounds great, but first we need to agree how we want our release process. Having a list of things to fix for the next release sounds very good, but we need community input on what's important. For instance, voting on preferred issues on Trac.  

It's possible to see tickets in Trac sorted by voted:https://lampsvn.epfl.ch/trac/scala/report/9
And tickets in Trac sorted by length of cc list:https://lampsvn.epfl.ch/trac/scala/report/11
Surely some of these are out of scope for 2.8.0, but I think those lists (especially the cc list) give a good sense of what people care about. Perhaps we can encourage people on scala@ to upvote issues they feel strongly about.

Exactly my point.
iulian 

--j 

iulian

Thanks,

David


 

Cheers

 -- Martin

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

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Scalaz compiles and passes all tests, this time with specialization enabled.

I used:

Scala 2.8.0-20100429.015228-+
"org.scala-tools.testing" % "specs_2.8.0-nightly" % "1.6.5-SNAPSHOT"
"org.scala-tools.testing" % "scalacheck_2.8.0-SNAPSHOT" % "1.8-SNAPSHOT"

The only code change [1] needed since RC1 was to Zipper#move. It was
annotated with @tailRec, and used to compile. The compiler now doesn't
optimise this, because the 'this' reference changes. The compiler
error message was clear, and the code change was trivial.

-jason

[1] http://github.com/scalaz/scalaz/commit/93d937239a7192b22fc1205db622a4af5...

On Tue, Apr 27, 2010 at 5:34 PM, martin odersky wrote:
> Adriaan and I think we might have fixed the last remaining problem reported
> by David. Our assumption is that it's the same as ticket #3349, which we
> could fix. This means we are probably ready to roll an RC2 at the end of
> this week unless something else gets reported.
>
> So, I'd like to stabilize trunk by tonight, which means that afterwards only
> uncontroversial bugfixes should go in.
> If anyone thinks that's too soon because they want to do some major change
> before that, please let me know now.

On Thu, Apr 29, 2010 at 09:25:58AM +0200, Jason Zaugg wrote:
> The only code change [1] needed since RC1 was to Zipper#move. It was
> annotated with @tailRec, and used to compile. The compiler now doesn't
> optimise this, because the 'this' reference changes. The compiler
> error message was clear, and the code change was trivial.

I caught a fish with that one? Sweet!

Maybe it's because it's late and you really enjoy letting return types
be inferred, but I can't convince myself it's correct in disallowing it.
Not saying it's wrong, but not sure. Did you try annotating the return
types and compiling it the way it was? If it's right to fail it, can you
see which target is not the same type as this?

Hook, line, and sinker!

Indeed, annotating the return type of Zipper.zipper, which used in the
chain of inferred return types was sufficient to TCO Zipper#move,
without restructuring the code.

The old inferred types:

Zipper#tryPrevious: Some[java.lang.Object with Zipper]
Zipper#previous: java.lang.Object with Zipper

Perhaps you could consider 'java.lang.Object with X' as equivalent to
'X' when considering if the type of 'this' changes. But I'm not really
bothered by this.

I've actually been adding explicit return types as I touch the code.
Apologies if this this jeopardizes the usefulness of Scalaz as a
collection of corner cases for the compiler and other tools :)

-jason

On Thu, Apr 29, 2010 at 9:56 AM, Paul Phillips wrote:
> On Thu, Apr 29, 2010 at 09:25:58AM +0200, Jason Zaugg wrote:
>> The only code change [1] needed since RC1 was to Zipper#move. It was
>> annotated with @tailRec, and used to compile. The compiler now doesn't
>> optimise this, because the 'this' reference changes. The compiler
>> error message was clear, and the code change was trivial.
>
> I caught a fish with that one? Sweet!
>
> Maybe it's because it's late and you really enjoy letting return types
> be inferred, but I can't convince myself it's correct in disallowing it.
> Not saying it's wrong, but not sure.  Did you try annotating the return
> types and compiling it the way it was? If it's right to fail it, can you
> see which target is not the same type as this?