Hi Simon and Bruno, On 3/10/24 7:00 PM, Bruno Haible wrote: > I think this would be a reasonable time after having made the Python > implementation > the default. I expect every package maintainer to run 'gnulib-tool' at least > once > in two years and report problems if they occur. Based on this assumption, we > could > drop gnulib-tool.sh two years after having made the Python implementation the > default.
Two years seems like a good amount of time for projects to prepare and report issues. From my limited experience, it seems that gnulib-tool is pretty stable feature wise. Maintaining them both for two years would be extra work, but should hopefully result in a stress-free transition. > That's not the plan. Most features have been implemented for good reasons. > There is nothing that we can't easily implement on the Python side, other > than error behaviour. Just echoing Bruno's thoughts here, but the hardest part of the Python rewrite is my lack of experience with the regular gnulib-tool. If I had more knowledge of gnulib, the entire gnulib-tool.py.TODO file would be done by now. :) I am not a GNU maintainer or anything. I think even my first contribution was only even a month ago with some build issues in Coreutils on FreeBSD. I discovered gnulib-tool.py while messing around hacking. Since I have no interesting projects at the moment, and gnulib-tool.py seems like it will save maintainers a lot of time cumulatively, it was an easy decision for me to work on. I am continuing to work on it and hope to have it in a good place for testing sometime this month. You all seem to have good ideas for testing so far. I am happy to help where possible once there is a more concrete plan. Collin
