bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

merging gnulib-tool rewrite


From: Bruno Haible
Subject: merging gnulib-tool rewrite
Date: Sun, 06 Aug 2017 11:11:42 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-83-generic; KDE/5.18.0; x86_64; ; )

Hi Dmitry, all,

First of all, my deepest apologies for not having pulled your gnulib-tool
rewrite into gnulib once you finished it. The reason was simply that the
project went from April to September 2012, and I stopped having time for GNU
in July 2012. I only "came back" recently.

If there's one thing I learned in that time, it is that I get nowhere if I
don't set priorities (which projects to work on) for myself. My priorities
are set for the next year or so, and they include only _occasional_
contributions to gnulib. Therefore I can not do this integration myself,
but I can help out with guidance.

In any case, I'm in favour of integrating it into gnulib.

> I'm amazed that someone still remembers this project. Looking at its
> sources, I see that there is room for improvement, but still the overall
> project structure may still be integrated into gnulib. I would be glad to
> continue working on the project in my free time,

This would be ideal!

> though my Python skills are a bit rusty.

The good thing about Python is that even with superficial knowledge of the
language, you can read and maintain code.

> As for parallelization, I think it may be a good idea to
> use Python 3 since it now has some form of Go-like coroutines IIRC.

Huh? I thought I insisted that we use Python 3 from the beginning. Anyway,
I think no one will be asking for parallelization once they use
gnulib-tool.py.

> Do you think it's a good idea to revive the old project? It seems that it
> may still be useful.

Yes, sure. I think the biggest lack, currently, is that there is no test
suite that would guarantee behavioural compatibility between the shell script
and the python program. But this is not a blocker; it can be mitigated by
having the gnulib users test one versus the other. And once enough users are
satisfied with the python program's results, it can be declared the "official"
one.

So, if you (or someone else) volunteers to work on this integration, I would
see the sequence of actions as:
  1. Merge https://github.com/ghostmansd/gnulib-python into gnulib.
  2. There were 52 modifications to gnulib-tool since April 2012. Do the
     same modifications to gnulib-tool.py, for consistency. (Most of these
     changes were quite small. The biggest one is the one from 2015-11-21.)
  3. Document how to use gnulib-tool.py, but mark it experimental.
  4. For several months, answer support requests from users.
  5. Once a sufficient number of users have used it and are satisfied with it,
     document it as recommended and make it the default.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]