Re: Blockers for Guile 2.2

[Luca Fascione]

In case it's useful, I'll share my impressions as a recent addition to this
group.

I have some experience with rolling out software, gathered in a different
field.
Where I come from we release often (I think we've averaged in the 30+ cuts
per year, roughly 2 every 3 weeks), and our users have tolerance for the
occasional
rollback, and they roll forward relatively happily.
One very important difference is that in that environment it is built into
the
infrastructure a solid mechanism for picking the software version per
project,
so that you could be working on several different versions of the software
in the
same day or so that were transparently tracked for you to stay on their
corresponding working files.

It seems to me the people that I hear speaking (maybe with the exception of
HanWen)
have a low level of confidence in the ability of the regression/test suite
to provide
adequate coverage of the scenarios needed by your current users.
(Otherwise I don't even know why this is a discussion in the first place)

I would consider this your highest priority: trusting your tests is
absolutely crucial.
A release going out that passes tests and fails in the field should be
brought to be
a "0 probability" event. This won't ever be the case for real, hence the
occasional rollback:
when user X rolls back, a test is made and added to the suite so this won't
happen again
(preaching to the choir, I get it). I wouldn't give a second of thought to
folks rolling back a
binary as long as a) you're proactive in saying clearly that there's be a
problem and here's
how you fix it (roll back, and roll forward once you get the next binary,
say);
b) this happens rarely, obviously.

The other aspect that I observe reading this exchange is that nobody is
talking about
Scheme source in client code. I see you discussing how to pick up the
differences between
Guile 1.8 and 2.2 in the shipped source, but I don't recall seeing a
discussion focusing on user-side
changes. And in fact, this is a similar point to the previous one: either
these differences are there and
are material or they are not. In the second case, you should go ahead and
move to 2.2.
In fact I'd think you ought to ship current-ish (read non 2.2-specific)
scheme source (with bugfixes)
with the new runtime, and let that soak in userland for a bit (say 2.24 is
that, and then 2.26 contains
2.2 specific source). As I read some people saying certain distributions
are already shipping
binaries based on Guile 2.2, I suspect maybe 2.22 (on those distributions)
is a passable
proxy for this stage.

In the first case (Guile 1.8 vs 2.2 actually makes a real difference in
source semantics and
correctness(*), forget about the speed) your first concern must be what to
do about users
migrating their source and what cost will that be, in terms of time
investment, instabilities
or defects introduced and all that, which will dominate your ability to
reduce your
maintenance exposure making sure the majority of your user base will in
fact pick up the new
release line.

(*) not that this seems to me a very realistic thing for the Guile folks to
do intentionally

Last thought: as I am currently learning Scheme and Guile, and I noticed
3.0.x has been out for a couple years now
and seems to be benchmarking with speeds comparable to the 1.8.x line
(according to their release notes).
Given the switch to 2.2 hasn't happened yet, and as I am reading through
these emails, it has been
a long process, wouldn't moving to 3.0 instead be a better way to
capitalize on the effort and push
out the next round of this level of pain to a later date?
(Again, I am expecting this has been discussed before, but still
occasionally it's good to re-evaluate
decisions: circumstances change, new evidence comes up, time goes by)

I do realize this will stir many folks, and that this subject is
understandably very sensitive,
but it's possible that a pause and refocusing could be of use. I feel a lot
of drive and
energy and dedication to the project from all of you, and it seems very
clear to me the folks
that are writing maintain very high ethical standard and truly want the
best for the project.
This is the reason why I joined lilypond-devel btw, the people are awesome.
(and I'll admit I also think the program is pretty cool ;) ).

However, I also think I observe you all having a difficult time trusting
that things will go well,
there seems to be a high level of fear that "something bad" will happen. If
I may propose a
perspective: don't have fear of that, because something will break for
sure.
Nobody can avoid that, but what you can do, and what will make a positive
difference to your
users is your ability to help them through the stumble, support them in
their difficulties,
and keep moving ahead together.

Thanks for your time, hopefully some of these thoughts can be of use
L