Re: development goals

[Han-Wen Nienhuys]

Neil Jerram escreveu:
> 2008/9/7 Han-Wen Nienhuys <address@hidden>:
>> OK - I will admit that interpreter/GC hacking is cool, but on the
>> downside, when I try to do anything, the intertia/resistance I feel in
>> the community here is a big turnoff for me.
> 
> Do you mean regarding releases (as you say more on below)?  Or/also
> the mailing list dynamic/responsiveness?  Anything else?

For a large patch (like the disputed GC patch), I got criticism of the
process I used to push it and complaints that it had multiple fixes
collated together. I was expecting criticism about what it changed,
i.e. I was hoping for more insightful comments.  It's hard to take
criticism seriously if it is only about cosmetics.

Also, the general idea that patches can only be committed if they are
'perfect' is not conducive to more rapid development.  I was rather
shocked that the idea of rolling back the change was considered a
better option than adding further fixes on top of it.

For example, there was the issue of x86_64 being broken by the
asserts.  I read complaints on the list, I got scolded at by Ludovic,
and a week later the code was still there.  I posted a proposed patch
(a single #ifdef!), to which I didn't receive a single comment.  When
I finally committed, I got a complaint that the commit message did not
have the right formatting.

Apparently:

- Rolling back a patch is preferred over fixing actual problems.

- Nobody has enough initiative to put a single strategic #ifdef in the
  code.

- If someone finally does take initiative, it's only ok if it is
  perfect.

I try not to goof up when pushing lilypond patches, but I do, up to
committing code that does not compile (yes, sue me).  When that
happens, generally people push simple fixes - there are 24 people with
push access, of whom 16 or so are active.

The people that push generally ask for review if they are unsure of
what they are doing, but when they feel certain, they do without
asking; I like that, because I don't have enough time to police the
master branch.  At ~15 commits per day I don't have time for that.  At
times, I have to request some corrections (missing regression tests,
style issues), but that is rare, and when I do I get prompt responses,
with the perpetrators pushing fixes on their own initiative.

There also are people that I know and trust to have full competence.
For example, Joe Neeman has rewritten all of the vertical spacing code
in Lily, and I don't pretend to judge or really understand his code
when he pushes.

You might construe that I would like to turn Guile development into
LilyPond development.  That is not necessarily the case, but I keep
misunderstanding what people expect in this community.  I am assuming
that developers in general are interested in a more lively and more
rapid evolution of Guile, but everytime I see habits and policies that
seem contrary to that goal.

>>> FWIW, I would like to run my code on other schemes -- not the same goal
>>> as this one, but it overlaps considerably. For me, I think that the path
>>> will be implementation of some scheme standard that supports modules,
>>> then migrating code over to that standard. I'm not sure about R6 though.
>> Is there a Rx/SRFI standard for modules? I always thought that module
>> system(s) was one of the unspecified areas.
> 
> R6RS specifies libraries, which are similar to modules.  (But probably
> much cleverer for separate compilation, and vastly more complicated in
> their semantics.)

Hmm .. curious, I thought one of the objectives of Scheme was simplicity.

>> When working with the devs here I continue to be puzzled by what the
>> objectives are.  For instance, we had 5 major (stable) releases in 11
>> years.  I have always wanted this rate to go up, and have tried argue
>> for that, but with 1.10 (or 2.0, whatever it is called) being in
>> preparation for 2.5 years at this moment, I don't see this changing.
> 
> For me, almost all of my time since becoming a maintainer has been
> absorbed by working on bug fixes, largely to do with slightly odd
> platforms (e.g. Mac) or architectures (e.g. ia64).  IMO it was
> worthwhile to focus on such bug reports soon after they were reported,
> because (i) the reporters are still around and interested enough to be
> able to provide more info and test fixes, (ii) I believe that running
> on more platforms will be good for the Guile community, and for Guile
> applications.

FWIW, I am shipping lilypond cross compiled on linux (ppc, x86_64, x86)
darwin (ppc, x86), mingw and freebsd (x86, x86_64). The stable release is
mostly working for that.

> Basically, my feeling is that Guile users have been badly burned by
> major release incompatibilities in the past, and I really don't want
> that to happen again.  Therefore my "straw man" plan is that

If anything, you should listen to your current users.  If you don't
listen to your current users, they will leave, and you won't be left
with any.

I'm one of the current users, and compatibility is the least of my
concerns.

But don't take my word. You should go out and ask other users too.  I
remember talking to Joris vd Hoeven (texmacs) several years ago, and his
complaint was that GUILE was very slow.  I didn't hear him mention
compatibility issues once

> - we stay on 1.8.x for a while
> [..]

>> At such a glacial pace of development, you would imagine that backward
>> compatibility would not be a concern
> 
> Huh?  That makes no sense to me.

Small projects don't live long enough to span 2 incompatible GUILE
releases.  The projects that do live long enough are few.  (LilyPond &
gnucash come to mind).

>> - after all, who plans for
>> compatibility over a five year span,
> 
> I believe that programmers' natural tendency is to plan for infinite
> compatibility.
> 
>> yet Guile continues to support
>> (by default!) the GH interface which was deprecated in 2002 (or was it
>> with version 1.4 in 2000?).
> 
> There you're right.  We can and should rip GH out now.  Actually that
> might make an excellent first example for documenting incompatibility.
>  (Anyone who really still needs it can take on the burden of
> maintaining the GH layer themselves.)

I probably wouldn't bother too much with documenting incompatibility;
bumping the version number to 2.0 is an easier way to deal with that.
Then again, as noted before, I am confrontational.

>> For LilyPond (and any other package that uses Guile, eg. texmacs,
>> snd), this is a problem, since we can not realistically ship anything
>> that requires the latest Git/CVS version to work.  Hence, my
>> improvements in LilyPond are held back by Guile's release scheme.  For
>> example, I wanted to use SCM rationals for various purposes in Lily
>> for a long time, but had to wait for the 1.8 release before I could do
>> this.
> 
> Are there items in master now that you are particularly wanting /
> waiting for?  I guess the GC is one, any others?

At the moment the GC fixes are one thing. Maybe I should look into 
backporting them, but the changes will be somewhat large.  

There is nothing really significant in the tree that I need desparately,
but I did contribute some features (a hook for memoize symbol) that I 
believe did not make 1.8.  I used those for measuring coverage of the
lilypond test suite.

Then again, with all the back & forth porting of changes between 1.8
and head, it's difficult to tell what is in 1.8 and what is not.

-- 
 Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen