Re: Script to generate ChangeLogs automatically

[Joseph Myers]

On Fri, 30 Nov 2018, Alfred M. Szmidt wrote:

> I disagree on that, you don't have to have any familiarity with that
> at all to make useful contributions to glibc, nor should we make it

If you're trying to add a new (public) function - which is quite a common 
thing for new contributors to try to do, they have some problem for which 
adding a new function to glibc seems like a solution - then it's likely 
you'll run into various of those areas.

> harder by requiring a complicated, hard to understand tool like git to
> just be able to poke around in history.  

As with other things, people become more familiar with it over time.  If 
you don't know C, you're probably not going to make many contributions to 
projects written in C.  If you have basic C, you may be able to contribute 
in some areas but not others; more C expertise may allow contributing in 
more areas.  Similarly, basic git allows basic investigations into 
history, and people can learn more advanced git over time.  I think some 
knowledge of git is just as fundamental nowadays for much free software 
work as some knowledge of C, the Unix-like command line or a text editor.

Projects can use different version control systems, just as they can use 
different languages.  In both cases, a more obscure choice may reduce 
accessibility to developers.

> understand history.  And while git is prevailant, it should not be a
> requirement that to one must be an expert in its use to be able to get
> something half reasonable out of it.  I'd go as far that how to do

"half reasonable" does not require being an expert.  "git blame" is more 
than half reasonable by itself, even without any knowledge of the other 
tools and the cases where you might want to use them or alternative 
options to git blame.

> these queries is outside most peoples daily git usage.  And this is

I think "git blame" (and analogues such as "svn blame" or "cvs annotate") 
is pretty basic usage of git (or any other version control system).  
Fancier variants such as naming a revision with git blame (to see what 
changed before the last change to a given line), or using git log -L (to 
see changes that only deleted code, etc.), maybe less so, but people can 
learn those over time when they're looking at issues where those tools 
turn out to be helpful, just as they can learn more advanced usage of C 
over time.

And of course people with difficulty debugging a problem can ask on #glibc 
or libc-help or libc-alpha (or any non-project-specific location) and get 
advice from people more experienced exploring glibc history with git, and 
likewise with any other project - we don't expect people to become expert 
at understanding and developing the code of a project in isolation, just 
reading instructions without experimenting and talking to other 
developers, the same applies to expertise in following the history.

> ignoring non-developers ... something that has been the nicest way of
> learning what is going on in a project is browsing the ChangeLog.

I find "git log -p --stat" useful for that sort of thing (reading commit 
messages and diffs depending on what seems of interest).  (Browsing list 
archives also shows things going on beyond just commits, if the project 
uses mailing lists.)

> Personally I'd rather not spend time learning a dozen VCS and rather
> spend it on doing actual work.  Most of my usage of git is via vc-mode
> in Emacs, is there some way of getting this information from there in
> a VCS agnostic manner?  I did not find anything like that, which is
> the big benefit of ChangeLog-style files (be them autogenerated, or
> manual).

I've not tried using vc-mode for this, but Paul Smith already explained 
how to use it for a "git blame" operation 
<https://lists.gnu.org/archive/html/bug-standards/2018-02/msg00000.html>.

-- 
Joseph S. Myers
address@hidden