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 ChangeLogs? 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 jos...@codesourcery.com