Jim Meyering wrote: > consider what it means: > You prepare everything for a release, test to your heart's content, > and then at release time you rerun gnulib-tool to update copyright > notices. Unfortunately, that might also pull in other (untested) > changes. Of course, we can control that, but it is a potential > source of trouble.
Just today, Patrick Leslie Polzer pointed us to the autogen.sh script used in findutils (mistakenly called 'import-gnulib.sh' although it does more than importing gnulib), see [1]. Look at the variable 'gnulib_version': If you set it to a date in the past, you eliminate this sort of trouble. And if you set it to 'HEAD', you track all changes like you currently do. If the coreutils 'bootstrap' script had the same configuration parameter, you would only - at some point before the release - change this variable from HEAD to the the current date, until after the release. > I'm inclined to stick with the status quo unless there's > a very strong argument for changing. There is also Brett's argument #2 in [2], which I find understandable. I'm trying to find a constructive solution that would be compatible with your and Paul's way of working. Bruno [1] http://cvs.savannah.gnu.org/viewvc/findutils/?root=findutils [2] http://lists.gnu.org/archive/html/bug-gnulib/2007-07/msg00102.html
