Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?

2014-11-14 Thread Gavin Smith
On Wed, Oct 29, 2014 at 10:39 PM, Eric Blake ebl...@redhat.com wrote:
 On 10/29/2014 04:29 PM, Diego Elio Pettenò wrote:

 Can't we just say that gnu-flavour automake is pointless and foreign should
 be the default? Or am I too opinionated on that?

 For GNU projects, the 'gnu' flavor still makes sense, even if it could
 use a little modernization such as easier automation of generating
 ChangeLog from version control.  And while these days, automake is
 probably used by more non-gnu projects (where 'foreign' may make more
 sense) than GNU projects, that's still not a good reason to toggle the
 default.  I like what the GNU Coding Standards represent, and deviating
 from them deserves a mention in configure.ac to make it apparent that
 you thought about it.


Having to either specify 'foreign' or creating files like ChangeLog
or AUTHORS is an extra step in initializing an automake project,
which would be a slightly tricky and involved process even without
this step. It's annoying that automake /could/ run, but refuses to
because you forgot to put AUTOMAKE_OPTIONS=foreign in Makefile.am.
Extra steps like this limit the usefulness and applicability of a
program Even if you intend to follow the GNU Coding Standards you will
not necessarily want to write all these files at the beginning. Or the
project may never be intended for release.

What about checking for these files in make distcheck instead? That
way you could initialize and use an automake build system without
worrying about it, but you would still get a warning when you were
thinking of making a release, when the project is in a more complete
state.



Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?

2014-10-30 Thread Arne Babenhauserheide (IMK)
Hi Flameeyes,


Am 30.10.2014 00:43, schrieb Diego Elio Pettenò:
 All good and well, but then I may have misunderstood Arne's original
 point. If he's trying to get the GNU style to be good enough

That means I did not make my point clear enough. Second try:


I don’t want to change the GNU style. I want to have an easier way to
*adhere to* the existing GNU style by providing default tool support for
creating the ChangeLog and AUTHORS file from versiontracking systems.

Having NEWS, README, ChangeLog and AUTHORS in a release tarball makes a
lot of sense, and having NEWS and README also makes a lot of sense in a
version tracking system (I see that every time I try to use a project
which does not have them).

It’s just that when using a version tracking system, the ChangeLog and
AUTHORS file mostly duplicate information which is already in the
version tracking system.

This isn’t true for all projects. With complicated history a generated
ChangeLog can become useless and when committing patches from others and
forgetting to change the user, an autogenerated AUTHORS file can simply
be wrong. But for most projects they should be valid.


Additional motivation for this: If I want to teach someone to switch
from a simple Makefile to autotools, I have to talk about

- configure.ac (this is mostly copy-paste, adjusting name and version)
- Makefile.am (copy-paste from a similar project or adapt a Makefile)

- autoreconf -i; ./configure; make (“copy this into the README”)
- NEWS (“put the newest version at the top”)
- README (“describe how to use the project and how to contribute”)

- AUTHORS (“name all people who contributed”)
- ChangeLog (describe the changes in GNU style. This means:
  - first line: date and author:
https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
  - changes indented.
- Start each changed file with a star (* file).
- optionally name the function.
- (a few special cases).
- Description after a colon and in following lines, also indented.
  - empty line between independent changes?


As you can see, how to write a conforming ChangeLog takes roughly as
much explanation as writing the configure.ac. And every new contributor
will have to learn how to do that (while the other topics are only
needed for the initial setup or for the maintainer).


Best wishes,
Arne

PS: I consider make distcheck as the gold standard for distributing
projects. I did not yet find a tool which gets close to matching that.
-- 
Doktorand
Gruppe: GHG

Raum: 435/410
Tel.: +49 721 608-22885
arne.babenhauserhe...@kit.edu

Karlsruher Institut für Technologie
IMK-ASF
Postfach 36 40
76021 Karlsruhe


0xA70DA09E.asc
Description: application/pgp-keys
attachment: arne_babenhauserheide.vcf

signature.asc
Description: OpenPGP digital signature


Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?

2014-10-30 Thread Diego Elio Pettenò
On 30 October 2014 06:45, Arne Babenhauserheide (IMK)
arne.babenhauserhe...@kit.edu wrote:
 Am 30.10.2014 00:43, schrieb Diego Elio Pettenò:
 I don’t want to change the GNU style. I want to have an easier way to
 *adhere to* the existing GNU style by providing default tool support for
 creating the ChangeLog and AUTHORS file from versiontracking systems.

Great. But people don't *want* to adhere to the GNU style, most people
just end up creating 0-sized AUTHORS NEWS and ChangeLog files, because
otherwise automake fails, and then they complain about autotools being
messy and requiring useless boilerplate.

 Additional motivation for this: If I want to teach someone to switch
 from a simple Makefile to autotools, I have to talk about

https://autotools.io/whosafraid.html

For 90% of the non-library projects out there this will cover enough
that is needed to start.

 As you can see, how to write a conforming ChangeLog takes roughly as
 much explanation as writing the configure.ac. And every new contributor
 will have to learn how to do that (while the other topics are only
 needed for the initial setup or for the maintainer).

So here is the usual disagreement. I don't like GNU style and I think
that imposing it and wasting people's time on it is not worth it at
all. Again I don't have stakes on the gnu style because I don't use
it. I don't want to use it. And I don't want to force anybody else to
use it. I usually make people happy when I tell them you can use
automake in foreign mode because then there is no 0-sized top-level
file there just to make it happy.


Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?

2014-10-30 Thread Arne Babenhauserheide (IMK)
Am 30.10.2014 10:15, schrieb Diego Elio Pettenò:
 On 30 October 2014 06:45, Arne Babenhauserheide (IMK)
 arne.babenhauserhe...@kit.edu wrote:
 Am 30.10.2014 00:43, schrieb Diego Elio Pettenò:
 I don’t want to change the GNU style. I want to have an easier way to
 *adhere to* the existing GNU style by providing default tool support for
 creating the ChangeLog and AUTHORS file from versiontracking systems.
 
 Great. But people don't *want* to adhere to the GNU style, 

Do not want to adhere to the GNU style or do they not want to bother
with creating the files? There is a very important difference in
motivation: People from the first group get what they want with foreign
style. People from the latter group however would be happy to use GNU
style, if it did not create additional work for them.

This change is for the latter group, since the former group can already
switch to foreign style by just adding a single parameter.

 most people
 just end up creating 0-sized AUTHORS NEWS and ChangeLog files, because
 otherwise automake fails, and then they complain about autotools being
 messy and requiring useless boilerplate.

Autogenerating the AUTHORS and ChangeLog would reduce this to a single
0-sized file, because nowadays most people understand that a README is
important -- I think the same will happen for the NEWS file, once code
hosting platforms start using the NEWS file as source to provide
human-readable news about projects. Then this would eliminate the
0-sized files.

Best wishes,
Arne

PS: I know your autotools mythbuster: It helped me a lot in adding
distcheck-support for my projects. Example:
https://bitbucket.org/ArneBab/wisp/src/6cf3f78205bec638f9eb8aba7344946e70bfd0e1/Makefile.am
Sadly much of my own autotools work also involved cargo-culting.
Note: Here you note that autotools need COPYING,
  but this is created automatically nowadays.
  You only need to provide it if you don’t want to use the GPL.
  - https://autotools.io/automake/options.html
-- 
Doktorand
Gruppe: GHG

Raum: 435/410
Tel.: +49 721 608-22885
arne.babenhauserhe...@kit.edu

Karlsruher Institut für Technologie
IMK-ASF
Postfach 36 40
76021 Karlsruhe


0xA70DA09E.asc
Description: application/pgp-keys
attachment: arne_babenhauserheide.vcf

signature.asc
Description: OpenPGP digital signature


Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?

2014-10-30 Thread Diego Elio Pettenò
On 30 October 2014 09:55, Arne Babenhauserheide (IMK)
arne.babenhauserhe...@kit.edu wrote:
 Great. But people don't *want* to adhere to the GNU style,

 Do not want to adhere to the GNU style or do they not want to bother
 with creating the files? There is a very important difference in
 motivation: People from the first group get what they want with foreign
 style. People from the latter group however would be happy to use GNU
 style, if it did not create additional work for them.

The problem is that it does, given that GNU style is not the presence
of those four files or not, but also involves the portability warnings
and further limitations designed for the GNU project, that they most
likely won't care about.

I get it, you want to get them to see the Light of GNU. But I'm not
there to indoctrinate on the style of ChangeLog people need to use,
I'm there to get people a working build system that does not drive
packagers crazy.

 This change is for the latter group, since the former group can already
 switch to foreign style by just adding a single parameter.

Thus why I'm saying I don't care. If you want to do that for the GNU
people I don't care, I just think it's a false assumption that people
won't be complaining about another of the GNU style rules at some
point.

 Autogenerating the AUTHORS and ChangeLog would reduce this to a single
 0-sized file, because nowadays most people understand that a README is
 important -- I think the same will happen for the NEWS file, once code
 hosting platforms start using the NEWS file as source to provide
 human-readable news about projects. Then this would eliminate the
 0-sized files.

Err, no. I mean no really. Autogenerating them may help sure, but I
don't think people understand a README is important — people get
*forced* to understand a README is needed, but for instance I wouldn't
use gnu style anyway because I call my file README.md so that GitHub
at least *renders* it correctly. So yeah, I still expect 0-sized files
all around.

 Note: Here you note that autotools need COPYING,
   but this is created automatically nowadays.
   You only need to provide it if you don’t want to use the GPL.

Which once again I'm not assuming people do. Because I've seen
packages in which the README and the source says MIT, but then they
got a default GPL COPYING in there. Which is bad, and I hope I don't
have to explain to you how and why.


Again, carry on, it can't make things worse but I'll still suggest
people to stay away from gnu style unless they are part of the GNU
project.


Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?

2014-10-29 Thread Diego Elio Pettenò
Can't we just say that gnu-flavour automake is pointless and foreign should
be the default? Or am I too opinionated on that?

Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

On 29 October 2014 15:27, Arne Babenhauserheide (IMK) 
arne.babenhauserhe...@kit.edu wrote:

 Dear GNU Hackers,


 In quite a few guides I saw people suggest using the foreign automake
 style to avoid having to create the required text files.

 The goal of this email is to get more people to use the GNU style, so
 the interface for understanding an autotools project becomes more
 consistent again: GNU style should become standard for all guides.


 Among the required files, NEWS is easy to create but cannot be guessed
 automatically because it is intended for humans, and README is becoming
 standard (again) due to most code hosting sites using it as the summary
 page. AUTHORS and ChangeLog normally only contain information which
 already available in most version tracking systems - and can be created
 easily from that.

 If autotools did this automatically, the barrier for using GNU style in
 the autotools with a version tracking system would be much smaller: Just
 write README and NEWS.


 I initially planned to just send a small example script, but that
 matured faster than I had expected, so you can now find it at



 https://bitbucket.org/ArneBab/autochangelog/src/tip/create-or-update-changelog-and-authors.sh

 If someone with git-foo could cleanup the git ChangeLog creation to
 conform with the GNU ChangeLog standard, that script should be a good
 working example.

 The script only touches files which were created by the script or are
 missing.


 Best wishes,
 Arne

 PS: I initially sent this mail to the autoconf list. The original
 discussion is at [1] and includes the gnulib script which roughly does
 for git what I propose here. Doing this in automake would have the
 advantage that all users benefit from the lower barrier of entry to the
 consistent GNU style.

 [1]: http://lists.gnu.org/archive/html/autoconf/2014-10/msg0.html

 --
 Doktorand
 Gruppe: GHG

 Raum: 435/410
 Tel.: +49 721 608-22885
 arne.babenhauserhe...@kit.edu

 Karlsruher Institut für Technologie
 IMK-ASF
 Postfach 36 40
 76021 Karlsruhe






Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?

2014-10-29 Thread Eric Blake
On 10/29/2014 04:29 PM, Diego Elio Pettenò wrote:

[we tend to avoid top-posting on technical lists]

 Can't we just say that gnu-flavour automake is pointless and foreign should
 be the default? Or am I too opinionated on that?

For GNU projects, the 'gnu' flavor still makes sense, even if it could
use a little modernization such as easier automation of generating
ChangeLog from version control.  And while these days, automake is
probably used by more non-gnu projects (where 'foreign' may make more
sense) than GNU projects, that's still not a good reason to toggle the
default.  I like what the GNU Coding Standards represent, and deviating
from them deserves a mention in configure.ac to make it apparent that
you thought about it.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?

2014-10-29 Thread Diego Elio Pettenò
On 29 October 2014 22:39, Eric Blake ebl...@redhat.com wrote:

 [we tend to avoid top-posting on technical lists]


Sorry, me sleepy and not paying enough attention.


  Can't we just say that gnu-flavour automake is pointless and foreign should
  be the default? Or am I too opinionated on that?

 For GNU projects, the 'gnu' flavor still makes sense, even if it could
 use a little modernization such as easier automation of generating
 ChangeLog from version control.  And while these days, automake is
 probably used by more non-gnu projects (where 'foreign' may make more
 sense) than GNU projects, that's still not a good reason to toggle the
 default.  I like what the GNU Coding Standards represent, and deviating
 from them deserves a mention in configure.ac to make it apparent that
 you thought about it.


All good and well, but then I may have misunderstood Arne's original
point. If he's trying to get the GNU style to be good enough for
more projects, I think that's a moot point because as you said most
projects use it outside of GNU, and they would probably still find
enough issues with it that they wouldn't use it — and they would
probably still complain about bad autotools doing bad things because
they copy-paste from the wrong project.

If we're talking of making life easier for GNU maintainers, I have no
opinion because I have no stakes on the matter at all.

Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/