[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using VC for change descriptions

From: Joseph Myers
Subject: Re: Using VC for change descriptions
Date: Thu, 10 May 2018 11:25:30 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Thu, 10 May 2018, Mike Gerwitz wrote:

> But then we're converting a simple problem (looking at changed entities
> in a ChangeLog) into one that has a variety of potential approaches

Actually, I'm taking a step back and saying that looking at changed 
entities in a ChangeLog is a means to some end in the course of developing 
a program, not an end in itself, and so looking at what the best means to 
that higher-level end now is.

> > I just don't think it actually helps the community to have such a program, 
> > or that people would want to use it.
> It's not a question whether people may want such a script---there are
> such people, here in this conversation and elsewhere.

That's only relevant if the people with a use for it are working on 
projects that choose not to use ChangeLogs.

What do such people do when working on, for example, the Linux kernel, or 
any number of other free software projects out there that do not use 

If such tools are significantly useful, presumably they already exist and 
are in use in that context, because there are so many developers working 
on so many such projects.  If they don't, I think it would clearly be best 
for people who find them useful to write them, as they have a much better 
sense of what fits their requirements in tricky cases; someone without an 
actual use for such a tool writing a script as a proof of concept for 
listing names of changed entities would inevitably end up with something 
less useful in practice, since they wouldn't actually be using the tool 
day to day.

> > For those packages where developers like workflows based on entity
> > lists, I expect ChangeLog format to continue to be used, with people
> > writing the ChangeLogs in whatever way they are used to without using
> > such a program.
> But that only applies if said developer is in control of the development
> process for that program.  If contributors weren't a consideration, then
> I don't think it'd matter what approach is used by a particular project.

The responsibilities of GNU package maintainers include recruiting 
developers.  Naturally the maintainers need to consider the effects on 
developer recruitment when making such choices.

Joseph S. Myers

reply via email to

[Prev in Thread] Current Thread [Next in Thread]