Re: moving scala trunk from svn to git

Should releasing a STARR be an atomic process?  You could enforce a linear history in its binary-repository (that would be separate from SVN and GIT).
I still think allowing branching is important, but limiting STARR version numbers could still support this.
- Josh

On Sun, Jun 12, 2011 at 5:03 PM, Paul Phillips <paulp@improving.org> wrote:

I guess this can do the job well enough.

% git describe --tags
2.9.0.RC3-143-g98447e7

Just my $0.02 worth...
Do we *need* to maintain buildability of past versions in Git?  I agree it's nice to have, but if it proves impractical to retrofit in this fashion then we can still drop the starr binaries whilst retaining the change logs, commit messages, blame info, etc.  So long as the SVN repository still exists (in read-only form), then past builds can always be reproduced (this isn't too far removed from the approach we took with locking down trac for the Jira migration)

As for a linear (and human-readable) numbering sequence, I propose build numbers. The Jenkins Git plugin [1] is capable of monitoring multiple branches, using any of them to trigger a build, and pushing build numbers back into Git in the form of tags.  This also means that references to revision number in which a bug was fixed can *really* refer to the version it was fixed (i.e. the build number in which it compiled and tested cleanly).
The catch here is that we'd probably need more powerful hardware to be able to deal with builds on demand (instead of daily).  But that's probably a worthy investment, given the benefits of faster feedback if a build should fail.

[1] https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin


On 12 June 2011 22:53, Josh Suereth <joshua.suereth@gmail.com> wrote:

Should releasing a STARR be an atomic process?  You could enforce a linear history in its binary-repository (that would be separate from SVN and GIT).
I still think allowing branching is important, but limiting STARR version numbers could still support this.
- Josh

On Sun, Jun 12, 2011 at 5:03 PM, Paul Phillips <paulp@improving.org> wrote:

I guess this can do the job well enough.

% git describe --tags
2.9.0.RC3-143-g98447e7

--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

As for a linear (and human-readable) numbering sequence, I propose build numbers. The Jenkins Git plugin [1] is capable of monitoring multiple branches, using any of them to trigger a build, and pushing build numbers back into Git in the form of tags.  This also means that references to revision number in which a bug was fixed can *really* refer to the version it was fixed (i.e. the build number in which it compiled and tested cleanly).

Again, this makes it very difficult to maintain a separate fork.  Jenkins would only be aware of the forks which it is configured to watch.  This is better than simply having a magic incrementing version number for scala/scala/master, but only slightly.

Daniel

On 6/12/11 3:40 PM, Kevin Wright wrote:
> Do we *need* to maintain buildability of past versions in Git?

Yes. It's not that hard.

On 12 June 2011 23:42, Daniel Spiewak <djspiewak@gmail.com> wrote:

As for a linear (and human-readable) numbering sequence, I propose build numbers. The Jenkins Git plugin [1] is capable of monitoring multiple branches, using any of them to trigger a build, and pushing build numbers back into Git in the form of tags.  This also means that references to revision number in which a bug was fixed can *really* refer to the version it was fixed (i.e. the build number in which it compiled and tested cleanly).

Again, this makes it very difficult to maintain a separate fork.  Jenkins would only be aware of the forks which it is configured to watch.  This is better than simply having a magic incrementing version number for scala/scala/master, but only slightly.

True, but even with SVN there would be the issue of conflicting revision numbers.
Presumably a true fork would fork everything, including build server, etc.  I find it hard to imagine a third party forking the codebase but still expecting it to be built and managed on EPFL's/Typesafe's equipment!
I'd consider something like virtualised Scala, where the intent is to ultimately merge back into trunk, to be a branch and not a fork.
 

Daniel

--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

-1...

I think a brain dead simple solution exists.   Give me time to write it up.

On Jun 12, 2011 6:48 PM, "Kevin Wright" <kev.lee.wright@gmail.com> wrote:
> On 12 June 2011 23:42, Daniel Spiewak <djspiewak@gmail.com> wrote:
>
>>
>> As for a linear (and human-readable) numbering sequence, I propose build
>>> numbers. The Jenkins Git plugin [1] is capable of monitoring multiple
>>> branches, using any of them to trigger a build, and pushing build numbers
>>> back into Git in the form of tags. This also means that references to
>>> revision number in which a bug was fixed can *really* refer to the version
>>> it was fixed (i.e. the build number in which it compiled and tested
>>> cleanly).
>>>
>>
>> Again, this makes it very difficult to maintain a separate fork. Jenkins
>> would only be aware of the forks which it is configured to watch. This is
>> better than simply having a magic incrementing version number for
>> scala/scala/master, but only slightly.
>>
>>
> True, but even with SVN there would be the issue of conflicting revision
> numbers.
>
> Presumably a true fork would fork everything, including build server, etc.
> I find it hard to imagine a third party forking the codebase but still
> expecting it to be built and managed on EPFL's/Typesafe's equipment!
>
> I'd consider something like virtualised Scala, where the intent is to
> ultimately merge back into trunk, to be a branch and not a fork.
>
>
>
>> Daniel
>>
>
>
>
> --
> Kevin Wright
>
> gtalk / msn : kev.lee.wright@gmail.com
> <kev.lee.wright@gmail.com>mail: kevin.wright@scalatechnology.com
> vibe / skype: kev.lee.wright
> quora: http://www.quora.com/Kevin-Wright
> twitter: @thecoda
>
> "My point today is that, if we wish to count lines of code, we should not
> regard them as "lines produced" but as "lines spent": the current
> conventional wisdom is so foolish as to book that count on the wrong side of
> the ledger" ~ Dijkstra

On 12 June 2011 23:49, Paul Phillips <paulp@improving.org> wrote:

On 6/12/11 3:40 PM, Kevin Wright wrote:
> Do we *need* to maintain buildability of past versions in Git?

Yes.  It's not that hard.

Fair enough... It's certainly nice to have!

On 13/06/2011 00:51, Kevin Wright wrote:
>
>
> On 12 June 2011 23:49, Paul Phillips > wrote:
>
> On 6/12/11 3:40 PM, Kevin Wright wrote:
> > Do we *need* to maintain buildability of past versions in Git?
>
> Yes. It's not that hard.
>
>
>
> Fair enough... It's certainly nice to have!

Just for the record: even once we migrate to Git, the old SVN repository
will not go away: it will just be made read-only. There is a great deal
of stuff in SVN that is not possible/practical to move to Git.

Hence, old versions can always be rebuilt from there, if necessary.
Toni

(PS: I'm on vacation at the moment, sorry I'm not participating more
actively in the discussion)

While this is true, git bisect could be a great way to try to isolate performance degradations from 2.8 -> 2.9 if we had a good performance test library.   I think trying to keep the history in GIT in such a way that you can go back, at least to 2.7.1 would be ideal.
As for a mechanism of storing, versioning, retreiving STARR builds, I'm working on a document.  Hopefully will be completed tonight.
- Josh

On Mon, Jun 13, 2011 at 8:10 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

On 13/06/2011 00:51, Kevin Wright wrote:

On 12 June 2011 23:49, Paul Phillips <paulp@improving.org
<mailto:paulp@improving.org>> wrote:

   On 6/12/11 3:40 PM, Kevin Wright wrote:
    > Do we *need* to maintain buildability of past versions in Git?

   Yes.  It's not that hard.



Fair enough... It's certainly nice to have!

Just for the record: even once we migrate to Git, the old SVN repository will not go away: it will just be made read-only. There is a great deal of stuff in SVN that is not possible/practical to move to Git.

Hence, old versions can always be rebuilt from there, if necessary.
Toni

(PS: I'm on vacation at the moment, sorry I'm not participating more actively in the discussion)

On Mon, Jun 13, 2011 at 3:37 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

While this is true, git bisect could be a great way to try to isolate performance degradations from 2.8 -> 2.9 if we had a good performance test library.   I think trying to keep the history in GIT in such a way that you can go back, at least to 2.7.1 would be ideal.

We do have a number of benchmarks on the scala-lang site. they are a good start. It would be good to add some other projects to this. Major issue is that, to keep things manageable, maintainers of included projects would have to
agree to update their code speedily to new Scala versions. In return for that they would get early warning of performance degradation, and in practice immunity from such degradations, because committers would get to know about the problem quickly and could correct before a release happens.

Cheers

 -- Martin

Agreed.   Partly what I was suggesting (for git bisect) was having a way to find when a particular microbenchmarked went about X time to run.   I'm not sure how feasible this is, given microbenchmarking noise.   For Sperformance, our initial goal is just to enforce O notation on methods we detect changing from say O(lg n) to O(n) or O(1) to O(n) etc.
A good reporting library is crucial here.   However the issue is how much SVN history to preserve in GIT.  I think as much as possible would be ideal.

On Mon, Jun 13, 2011 at 9:49 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Mon, Jun 13, 2011 at 3:37 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

While this is true, git bisect could be a great way to try to isolate performance degradations from 2.8 -> 2.9 if we had a good performance test library.   I think trying to keep the history in GIT in such a way that you can go back, at least to 2.7.1 would be ideal.

We do have a number of benchmarks on the scala-lang site. they are a good start. It would be good to add some other projects to this. Major issue is that, to keep things manageable, maintainers of included projects would have to
agree to update their code speedily to new Scala versions. In return for that they would get early warning of performance degradation, and in practice immunity from such degradations, because committers would get to know about the problem quickly and could correct before a release happens.

Cheers

 -- Martin

Would be nice with performance benchmarks for all collections & their methods.
Then if one could derive a sensible way to run those after each commit and insert the data into a build-servers history, so one could potentially mine it for regressions.

On Mon, Jun 13, 2011 at 3:54 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Agreed.   Partly what I was suggesting (for git bisect) was having a way to find when a particular microbenchmarked went about X time to run.   I'm not sure how feasible this is, given microbenchmarking noise.   For Sperformance, our initial goal is just to enforce O notation on methods we detect changing from say O(lg n) to O(n) or O(1) to O(n) etc.
A good reporting library is crucial here.   However the issue is how much SVN history to preserve in GIT.  I think as much as possible would be ideal.

On Mon, Jun 13, 2011 at 9:49 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Mon, Jun 13, 2011 at 3:37 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

While this is true, git bisect could be a great way to try to isolate performance degradations from 2.8 -> 2.9 if we had a good performance test library.   I think trying to keep the history in GIT in such a way that you can go back, at least to 2.7.1 would be ideal.

We do have a number of benchmarks on the scala-lang site. they are a good start. It would be good to add some other projects to this. Major issue is that, to keep things manageable, maintainers of included projects would have to
agree to update their code speedily to new Scala versions. In return for that they would get early warning of performance degradation, and in practice immunity from such degradations, because committers would get to know about the problem quickly and could correct before a release happens.

Cheers

 -- Martin

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang