Re: Time to fork a guile-2 branch?

[David Kastrup]

"address@hidden" <address@hidden> writes:

> On 13 août 2012, at 11:14, David Kastrup <address@hidden> wrote:
>
>> Graham Percival <address@hidden> writes:
>> 
>>> On Mon, Aug 13, 2012 at 09:38:15AM +0200, David Kastrup wrote:
>>>>> 3. Where there are significant changes to component .scm files for
>>>>> guile V2, these will also be converted into a shim similar to lily.scm
>>>>> and will have <file>-guile-1.scm and <file>-guile-2.scm files
>>>>> produced.
>>>> 
>>>> Personally, I am almost in favor of a rather hard cut where we switch
>>>> from Guilev1 to Guilev2.  The problem with that is that such a step
>>>> cannot really be prepared separately since it would likely get code
>>>> outdated: we had that problem previously.
>>>> 
>>>> Most direct would be a hard cut: exchange the Guile version, and get
>>>> everybody working furiously until LilyPond works again.
>>> 
>>> I'm fine with this, perhaps immediately after 2.17.0 comes out?
>>> Provided that the regtests compile, I have no trouble switching to
>>> it for 2.17.1 regardless of what that might do to user scores
>>> (since nobody should be using 2.17.1).
>>> 
>>> Note that GUB will need to be updated to compile guile V2, and
>>> also that if that update is done poorly then GUB would lose the
>>> ability to compile 2.16.x.  IIRC that happened with the 2.12
>>> branch, or at least the compile needed some manual hacks in order
>>> to complete the build.
>> 
>> The problem I am seeing here is a scheduling problem.  We have two
>> pent-up changes.  One is changing from Guilev1 to Guilev2.  The intended
>> user-visible change is no change at all except for performance.
>
> For me it's a question of time more than anything else.  If Ian thinks
> that he can get the Guile 2.0 stuff pushed in the next couple weeks,
> it's worth it to hold off on skyline stuff.  Otherwise, I'd like to
> get the skyline stuff in there ASAP, as I am sure that it'll take
> several versions for all the bugs and performance issues to be ironed
> out.

Ok, I have forgotten something: we actually will have _three_ pent-up
change sets.  I am putting quite a hard freeze on the 2.16 branch so
that we have a good chance to put it out in good shape.  There are
already several patches on countdown that make good sense to get into
2.16.1 after seeing enough exposure in 2.17.0.  If we already clobber
2.17.0 with long-term unstable material, the testing for the
after-2.16.0 rush will not happen.

Keith has a regression fix, I have a few performance and usage things,
John has a build system overhaul.  I'd like to see those get out as
2.17.0 before the real mess with the code starts.

My personal preferred order after 2.17.0 would be Guilev2, then skyline.
Preferably properly rebased instead of a merge mesh.

However "preferred order" is based on the assumption that after the
release of 2.17.0 in a state reasonably close to 2.16.0 both Guilev2 and
skyline are in a state fit for merging and testing.

The skyline branch, apart from not being rebased, is in that state right
now, or at least that is the claim.  If a Guilev2 branch can get close
to that state by the time we put out 2.17.0, the "preferred order" comes
into play.

-- 
David Kastrup