Re: Concerns about GNU Bison maintenance.

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-08-06 01:35, ams@gnu.org wrote:
> What Jose mentioned, but also -- this all reads as if the GNU Bison
> maintainer is doing an excellent job adding new features and moving

Where can I see a "product management roadmap" of Bison features: who
are the stakeholders? Who is asking for what feature?

When new features are just items that pop into the maintainer's
head, that's a personal research project.

I don't think you can take that attitude with respect to a mature
piece of the GNU system.

> Bison forward.  There is no obligation in keeping backward
> comptability for ever -- indeed, the directive has been marked
> obsolete for over 10 years!

OK, so keeping things working is an example of what is not an
obligation. What are examples of what obligations are, and which ones of
them are in conflict with keeping things working and compatible (even
if that itself is not an obligation)? Is there an obligation to
keep pumping out new features, and to whom is that owed?

The %pure-parser directive is just a spelling; it could be internally
translated to the new spelling at the AST, token or even character
level, so then the rest of Bison just internally deals with the new
representation of the syntax. I don't agree that there is a difficulty
in maintaining it, and for a parser generator maintainer to assert
such at hing is particularly ironic; that should be someone who snaps
his or her fingers, and the tokens and the trees sit up and beg.

It's not acceptable to declare it obsolescent; certainly not when
at least another Yacc implementation has a compatible extension with
same directive. There is a concept of language at play here.

Look, "egrep" has been obsolescent for 30 years; we still have it.

Backtick syntax for shell command substitution is obsolescent; we still
have it, and it obligingly executes without generating warnings about
obsolescence. (In spite of there being no "obligation" to support
it).

I can write code in the ISO C90 dialect today, if I'm so inclined,
and it works fine.

Code with K&R function declarations and definitions can be built
today with a GNU toolchain.

GNU stands for excellent backward compatibility, in my mind,
and situations like the Bison project stand in stark contrast to that.

I think what we are going to need is a "bison wrapper" tool.
Here is how I envision it: the wrapper tool understands a stable,
conservative version of the Bison input language. It interrogates
the build environment to determine what version if Bison is installed,
and then generates a version of the grammar file adjusted for that
dialect. It then runs Bison, and then post-processes Bison's outputs
to make further necessary adjustments to get something buildable.

> If you are required to use a 10 year old version of Bison, then the
> best thing to do is to commit the generated files into VCS -- this is
> really no different than for GNU Autoconf/Automake.

Distros still have old versions of Bison (easily as far as ten years),
possibly because they have discovered that Bison upgrades are
radioactive.

Committing derived objects into version control is an anti-pattern
in configuration management; it must be done only when absolutely
necessary (like solving a chicken-and-egg problem for the users,
when the derived objects are built with the program that the project
provides.)

I'm absolutely not required to use a ten-year-old version of Bison,
except by the circumstances whereby the current one breaks my code.
Ideally, I just want to use whatever the distro provides, and have
everything work.

By and large I don't have anything like this problem with compilers,
libraries, and other utilities.

In any case, my git history is done. I can't go back ten years and
wish that the code had a checked-in version of the Yacc
output which had been produced then. The ten year old commit doesn't
have it, and that's that.

I do have the ten-year-old executables.

Speaking of which, GNU/Linux systems will run those executables!

> It also seems that the maintainer is _very_ quick to fix issues, it

I'm also very quick to fix issues, and likely so are you.

The restaurant down the street is quick to give you a new bowl
of soup if you find a fly, and not charge you for anything.

I fix issues quickly if I caused them, because I'm embarrassed.

If you don't cause issues, then you don't have to be tap-dancing
to convince people that you actually do have a good attitude.

Fixing issues in Bison upstream doesn't fix the installations.
Even if the fix is quick at the head of the stream, the user
isn't going to get it until the distro updates the tool,
which could take years.

> would be an impossible task to ask maintainers to test every single
> version released on every single GNU/Linux system.

What you can do is actually get in contact with some of the
downstream maintainers of the package. Are they picking up the
pre-release version at all?

Because testing is such a big challenge with a lot of unknowns, maybe
the thing to do is to adopt a different development strategy than
"move fast and break things".

> Not only that, but
> Ubuntu is a non-free GNU/Linux system, and our priorities are for 100%
> free GNU/Linux systems.

The system as such may not be 100% free, but software that /is/
100% free gets built on Ubuntu, and some of it requires Bison. We
have free systems; those can be used. I just threw out Ubuntu as an
example, admittedly a bad one. In hindsight, I don't think I should
have suggested that GNU maintainers should struggle with Ubuntu
distro builds.

> You mention POSIX, but we do not follow POSIX slavishly.

My empirical observation is that GNU/Linux in fact does follow
POSIX rather slavishly, and is even influential on the
directions POSIX takes.

As a result, the POSIX conformance in a GNU/Linux system is excellent,
and I think it has long surpassed commercial Unixes, not to
mention the BSDs.

There is a history of of stating the position of not following POSIX
slavishly (going back to Stallman's famous "POSIX me harder")
which is very suave and all, but the actual observed behavior is one
of pretty dogged conformance.

> We are quite
> free to ignore what it says.  Even so, GNU Bison does implement it to
> the limits it makes sense.

I only mentioned POSIX because of the y.tab.h issue. Pure parsing is
not a POSIX feature, so POSIX is not directly relevant. Yet it the
feature interacts with the concept of what y.tab.h is for;
the problem could have been prevented by observing what POSIX
says y.tab.h is for, and not putting anything else in it.

> Overall, I think your characterization is unfair, the maintainer
> acknowledges the pain you are experiencing, is trying to find a way
> forward and is doing excellent work on making GNU bison better and
> better for each release.

By what metrics?

I'm sorry, but failing to even build is not an objective example of
"better and better".