On Mon, 3 Dec 2018, Alfred M. Szmidt wrote: > Git still isn't a requirement to be able to contribute to glibc or the > rest of the GNU project, you can pull the e.g. tarball, make a patch, > and send it to libc-alpha. The change might be applicable to master, > it might not, but that is the same situation if you checked out a copy > of the glibc from a year back.
You can do that, but if you want the patch to go on master it's making things harder for yourself if you work only from the tarball. I think the same applies with other limitations - such as if you ignore the list archives and bug tracker when the history points to those being relevant, or if you try to investigate the history using only some limited subset statically extracted from it using a script rather than exploring the full structured history data as appropriate for your issue. I don't think such artificial limitations should be a significant consideration in choosing tools and standards for GNU software development. Use of distributed VCSes is good, but it's good because of the increased power they provide in exploring history compared to centralized systems, and because in general it's good for people to be able to get their own copies of such metadata (people should be able to fork the whole project if they wish, not need to rely on a single central copy of any of the data), rather than because working mainly offline without access to the hosted tools is an important consideration in choosing development practices. (If you want, you can rsync copies of the glibc list archives, and access bug tracking data using the REST API, to get local copies of that data.) -- Joseph S. Myers [email protected]
