On Sat, 1 Dec 2018, Richard Stallman wrote: > > You need to know some C to contribute to a package written in C. > > Similarly, I think it's reasonable to expect knowledge of some git to > > explore the history of a package using git. > > Those two issues look similar at a superficial glance, but they are > fundamentally very different. It is impossible to understand a > program without knowing the language it is written in. But git is > just a development tool. It is only marginally necessary -- not > crucial.
I think some version control system is crucial for large-scale software development - meaning the version control system used by the project you are working on (modulo the ability to use e.g. git-svn to have access to git facilities when using a project hosted in SVN - which many people do, because they want the greater power and familiarity of git). Likewise, a bug tracker. Likewise, some means of having development discussions around proposed changes, whether that's a mailing list, a pull-request based system, or some other arrangement for discussions. Likewise, the ability to search past discussions in those places. (I know you've said in <https://lists.gnu.org/archive/html/bug-standards/2018-01/msg00023.html> that mailing list archives and bug trackers are "too much trouble to access", but I think that's very far off the mainstream of free software development, where while people might occasionally be developing offline, e.g. replying to email offline while on a plane, the vast bulk of the time they have a browser immediately to hand, and find their development work substantially handicapped on the occasions when they are working offline without access to those resources.) Some system for real-time communication (glibc has #glibc IRC on freenode) is also very valuable. The typical developer having trouble using git to explore history can ask for immediate help there. I agree with Carlos that future new GNU developers will all have a working knowledge of git. We should be looking to the tools that future developers will be using when designing the standards, not to those that developers are used to from the past - rejecting tools that are non-free, accepting tools that improve the power of our development environment without being adverse to principles of software freedom. I think that we should respect the experience of non-GNU free software developers managing very large non-GNU projects (e.g. the Linux kernel) with the above tools, but not using ChangeLog format, as a proof by example that ChangeLog format is not required to be able to answer all the questions about the history of the code that arise in practice in development. There are often complaints about the Linux kernel not consistently using issue tracking; before it used version control, and when it used non-free version control, there were complaints about that; but git works very well for the Linux kernel (having been designed for it!), without needing ChangeLog format. > In any case, remember that the problem with git is that its commands > to study the history predictably fail in certain cases. Predictable failing (because the tool does some well-defined thing and a user can understand what that is, and the failure cases) can be better than unpredictable failure (because the tool tries to handle too many special cases). > The program I want people to write would work around that failure. You said a program needs to give "correct output in all cases that can appear in glibc" <https://lists.gnu.org/archive/html/bug-standards/2018-11/msg00012.html>. Apart from being a stronger requirement than previously stated in <https://lists.gnu.org/archive/html/bug-standards/2018-05/msg00011.html> "reliably enough that errors are rare and not a problem", it's not one the maintainers can realistically confirm to be met, simply because there are too many source files (17000), many of which none of the current maintainers are familiar with. Such a standard would effectively prevent any large, longstanding GNU project whose maintainers have changed over the years from using such a program. I think the GNU project should trust package maintainers *more*, not less - delegate more to them regarding technical decisions of when particular scripts or means of using version control are sufficiently good for understanding the package history. -- Joseph S. Myers [email protected]
