Re: News about the macro archive

[Tom Howard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Peter,

>  >> @license AllPermissive
>  >
>  > Sure I can, but can't I update the formatter instead? :D
> 
> If you care to write Haskell code. ;-)

If I have to, I have to.  Was the above permission to add long licence
support, or just a jib?

>  >> Yes, but editing the files manually isn't good enough.
>  >
>  > Um..  sorry if this is a stupid question, but why not?
> 
> If you look at the files in CVS now, you'll notice that they
> are extremely consistent. They are all formatted alike,
> there are no superfluous empty lines, the keywords are
> ordered the same everywhere, etc. This consistency is
> guaranteed by the formatting engine.
> 
> When the licenses are added to the m4 source, I want them to
> be consistent too. They should be spelled the same way, they
> should appear at the same place in all macros, they should
> use the same formatting. Doing that manually is a lot of
> work and probably bound to fail ... letting the tool do it
> is a matter of calling

What is the difference between getting the tool the check

dnl @license AllPermissive

and

dnl @license
dnl   Copying and distribution of this file, with or without
dnl   modification, are permitted in any medium without
dnl   royalty provided the copyright notice and this notice
dnl   are preserved.

?  I'm not suggesting that contributors should be able to put whatever
they want there, but is strongly believe it should be the complete licence.

>   genarchive m4src/*m4
>
> and then it's done.

Yes, I just noticed everything has moved :(  I'll get to that in another
email.

> So it's my turn to ask a stupid question: Why do you want to
> do the job _manually_ if all you had to do is to add
> @license AllPermissive into the files and let a machine do
> it?

I just looked at the latest tar ball an noticed that the all the m4
files have the short licences.  I'm stoked that the version on the web,
cvs and in the release are the same, but they really need to have proper
licence and copyright information in the files, rather than just in the
documentation.

>  >> That's what my tool is doing, and I will run it once I
>  >> know all macros are properly assigned.
> 
>  > But this (what I've added) means your tool doesn't need
>  > to do anything regarding the licence, except generate the
>  > appropriate html :)
> 
> No, that's not right. My tools spits out the m4 file in a
> canonic version as well as the HTML files.

I'm not saying that it doesn't, I'm saying that it doesn't need to.
Also, I don't know where the canonic version you are referring to is.
It's not part of the release.

Why not just have the tool check the formatting to make sure they meet
the guidelines and generate the html?

>  >> So please just use @license for now.
>  >
>  > Well, :( if you definitely want to generate the licence
>  > info, I'll get awk to swap over the one's I've already
>  > done. Give me the nod and it's as good as done.
> 
> Yes, that would be nice. Thanks.

I've got to play catch with the cvs layout change first, and while I"m
doing that I'll wait and see how this conversation pans out.

>  > Why are you generating the m4 files for release?
> 
> I don't generate them "for release". I run them through
> axlint as part of the build process before I commit them
> into CVS, even. All macros you are seeing in the CVS
> repository now are generated files in a way, yet they are
> the authoritative files too. And axlint does a lot more than
> just formatting: It enforces several points of the policy
> (like Obsolete handling), it catches missing keywords,
> misspelled keywords, malformatted arguments, etc. I only
> commit my changes after axlint finds nothing more to do.
> That's why the files are so consistent in CVS now, and
> that's why I can distribute them in verbatim now.

That's very cool, so is there any reason why we can have verbose licences?

> 
>  > I don't understand why you don't have the same m4 file in
>  > CVS, tar.gz and on the website?
> 
> I do. The website even links directly into CVS for the
> download.

I just noticed this.  Much better thank you.

>  >> Yes, that would be great, but this is a secondary
>  >> concern for me. The average everyday user can use the
>  >> web site or download the release archives.
> 
>  > You might disagree with me on this (and let me know if
>  > you do), but the more you allow the user to do
>  > themselves, the less the maintainers need to do.
> 
> That's not my experience. For years the software to format
> the entries was part of the release (macro2html.cxx and
> genindex.pl), and it didn't make one bit a difference in
> terms of quality of the submissions' markup. I had to edit
> the submissions a lot back then, too.

What was the submission procedure?  Was it still "email it to me"?  If
so, then I'm not surprised.  Instead you should have been telling them
to grab the cvs, add your changes, make sure the html output is correct
and not other errors are reported, then submit a patch.

> I agree that it would be nice to distribute the tool chain,
> but it's not my primary concern.

That's the only way to get the users to check their macros before they
submit them.  This is a job they should be doing, not the maintainers.

>  > For instance, with the macros I submitted, you had to go
>  > through each one and make the appropriate changes to make
>  > it work with the html generator.
> 
> Where exactly did you have problems?

I tried stick to the format, yet you still had to make changes.  There
was no way for me to check if the format was correct before submitting.
 As a macro contributor, I should be able to do that.

>  >> I don't know. I have a pretty sophisticated software written
>  >> already. Rewriting that in yet-another-language doesn't
>  >> sound like an efficient use of resources to me.
> 
>  > But it wouldn't be a rewrite as we already have gendocs
>  > to work from.
> 
> Let's put it differently: I _do_ have pretty sophisticated
> software, and I will rather spend my time on improving that
> than spending my time working on a different software. I
> don't see the point. If you want to spend your time
> improving gendocs.pl, then please go ahead. I can hardly
> stop you, can I? :-) But the chances that I'll throw away
> the system I have been developing for the last couple of
> years in favor of a new one are slim, to put it carefully.

I'm not asking you to throw it away.  It can still be used as a tool for
checking macros, however it's not what the archive needs.  The archive
needs a tool that most developers can use, so they can check the macros
before they submit them.

>  > My main goal at for the ac-archive is to achieve
>  > unification.
> 
> What exactly constitutes unification?

Get all the features that you need and that everyone else needs, all in
one place.  It is inefficient and confusing to the community to have two
archives.  I would even go as far as saying it's stifling extensions to
autoconf (and now automake).

> Could you please outline the steps that you think should be
> taken in order to further unification?

- - Implement a simple build process that just generates the docs (this
could be optional) and provides 'make install' which just copies the m4
files (and the docs if generated) into their correct location.

> What do you intend to
> do in order to reach that goal?

Whatever is needed. e.g. the configure files, the makefiles, do whatever
work is needed for the docs generator.

> What do you expect me to do
> in order to not stand in the way?

I don't expect you to necessarily stand in my way, but as always when
people have different goals, their actions may conflict.  What I was
saying is that I'm willing to do whatever work is needed in the case of
those conflicts as I'm certain that in the end they will only be technical.

>  > I'm already helping in terms of maintaining content by
>  > doing the licence changes.
> 
> I know, and it is very much appreciated.

No a problem.

>  > I'm also more than happy to [do the obsoletion of
>  > macros].
> 
> A minor request: Since you do edit the macros for license
> stuff anyway, could you watch out for macros that have the
> 
>   dnl obsoleted: some reason

grep -l obsoleted ac-archive/m4src/*.m4

> line in them and turn that into
>
>   dnl @obsoleted some reason
>
> ...? If nothing else, that will make it easier to identify
> those macros that need to receive the AX_OBSOLETE treatment
> later.

No need to change it twice, but if you insist, then something like

for FILE in `grep -l obsoleted ac-archive/m4src/*.m4`; do
        sed 's/dnl[ \t][ \t]*obsoleted:/dnl @obsoleted/' $FILE > $FILE.tmp;
        mv $FILE.tmp $FILE;
done

should do the trick.  I would need to test it first of course.

> Another thing that would be _very_ nice is to break up
> 
>   @author person 1, person 2
> 
> lines into
> 
>   @author person 1
>   @author person 2
> 
> ..., because that will generate nicer copyright statements
> when the time comes.

Well, the release tar ball doesn't have generated m4 files, so what's
the point?

Cheers,

- --
Tom Howard

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x433B299A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9X4zw1G4ZUM7KZoRAmvbAKCDdiEGYJP7LqhxGmgsHIM9I48j5ACfRDEZ
nyx3ekjnoRyYCIzPtnGlYWs=
=tkFe
-----END PGP SIGNATURE-----

tomhoward.vcf
Description: Vcard