Re: News about the macro archive

[Tom Howard]

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

Hi Peter,

On 25/01/2005, at 5:59 PM, Peter Simons wrote:
>> Tom Howard writes:
>>
>>> 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.
>>>
>>> ?
>>
>> Look, we are running in circles. I am doing this little
>> Macro Archive project for _fun_, and all this debate is no
>> fun at all. So I am out of it.

Sorry, I didn't mean to spoil your fun, I just don't understand why
you are so against a verbose license being in the source files.

>> Here is the deal: If you would like to help me with the
>> archive, then please modify those macros where the author
>> has agreed to relicense it to (a) state
>>
>>   dnl @license AllPermissive
>>

Already done.  See previous email, well one of my previous emails ;)

>> in the prelude, and to (b) have _no_ additional license
>> disclaimer in the m4 source code.

Done.

>> If that is not what you want to do, then feel free to do
>> something else, but please do it in a branch. Then my
>> formatting engine won't see it, and you have Card Blanche.

Well there is no point doing anything in a branch unless it's going to
be merged in at some time.  Isn't that what Guidod has at the moment
anyway, An uber-uber branch?

>>> I don't know where the canonic version you are referring
>>> to is. It's not part of the release.
>>
>> The canonic versions are in CVS, for crying out loud. I
>> check out the m4src tree, then I run axlint over every file,
>> then I do "cvs diff", then I check those files that have
>> been modified to see what the tool wants to change; and if
>> it is alright, then I commit.

OK, slow dow.  We are obviously not understanding each other.  You
said that your tool will generate the verbose license information from
@licence AllPermisive.  What I don't know is where it generates this.
It's not in the cvs, it's not in the release tar ball and it's no on
the version on the web (which is now the cvs version anyway).  So
please tell me where it generates it.

>> It's not like I haven't explained that a dozen times before.
>> It's not like I didn't offer you a copy of the tool so that
>> you could try it out yourself. It's not like you haven't
>> been listening because you desperately want to rewrite the
>> entire engine from the scratch for some unfathomable reason.
>> Wait, was that right?

You said installing the software to be able to use the tool is quite a
task, hence I have avoided it.  Is it not such a task anymore?

>>> I'm not asking you to throw [your software] away. It can
>>> still be used as a tool for checking macros, however it's
>>> not what the archive needs.
>>
>> That from a guy who has subscribed to the mailing list about
>> a week ago. You have no idea how the archive work, you have
>> no idea what is going on behind the scenes, but you know
>> better already what "the Archive needs" than I do, and I
>> have only been maintaining it for six years. Hehe.
>>
>> Way to go, Tom.

Dude!  I know a hell of a lot about maintaining a open source project,
and yours seems to be struggling badly.  Open your eyes.  The autoconf
macro archive should be something so simple, yet the way you have set
it up has resulted in a fork (Guidod archive).  For such a small
project, that says so much, but what's worse is that the Guidod's fork
is ranked higher than yours (using Google).  Doesn't this tell you
anything?  I'm trying to help you clean up this mess, so there is only
one archive.   This cannot be done until it provides the features that
the users and contributers need.  Yes need.

As a contributor, I need a simple way of taking the macro I use in my
project and submitting it to the archive.  The simplest method is that
a format for the m4 file is specified, I stick to that format and
whenever I make a change to the macro in my project, I can just send a
copy to the archive (either via a m4 file or via a patch, or however
the submission procedure specifies).  Anything that requires me to
have a different format for the macro in my project and to what I
submit, is broken and will not work.  This is the reason why the xml
macro format died.

As a user, I need a simple way of getting the archive and installing
it.  Manually copying of files is not a proper installation procedure.

I may have been on the list for a very short time, but I am both a
contributor and an user.  The reason why your archive is in so much
trouble is probably because you show such distain for the opinions of
people like myself.

BTW nice way to attack the person rather than the topics.  Way to go,
Peter.

>>> The archive needs a tool that most developers can use, so
>>> they can check the macros before they submit them.
>>
>> That tool does exist and it is called macro2html.cpp, or
>> genhtml.pl, or whatever it is called by now; and it has been
>> distributed for years without any observable effect on
>> anything. That's why I stopped distributing it. (Plus that
>> little sf.net thing, but that's another story.) So pardon me
>> if I don't believe that this tool is what the archive is
>> really lacking right now.

Well, in a way your right.  The only reason I said that was needed was
to placate you, so there would be a way of creating the docs for the
users.  Really, it's not needed.  All the user really needs is `make
install`

>> If you want to do something with it, go ahead, but please do
>> it in a branch.

You know I won't.  I've already explained that unification is my goal.
Creating another branch would only take us further from that.

>>>> 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.
>>
>> An Automake-based build system does exist already and is
>> found in CVS as well as in the recent release archives. You
>> can say "make install" and everything works as expected.
>> Once I'll come around to polishing the source code, I'll
>> check the other stuff into CVS and then you'll be able to
>> rebuild the documentation too. It's all working already.
>>
>> So I guess that point has been taken care of.

Yes, it is there now, but it was not when I started working on it, was
it?  It's kind of hilarious that you you can berate my opinions
because I've been here for such a short time, yet refer to an existing
build system as though is been around for ages, thats being
implemented since I joined (I might also add, after I added the very
same in ac-archive-build).  Hilarious!

Cheers,

- --
Tom Howard



- --
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

iD8DBQFB9w9qw1G4ZUM7KZoRApYkAKCrLArgTWhMBXa9GEritw5wGEHxoACgi76l
DVumMg7cEjduUiAdBfj++NA=
=EMXT
-----END PGP SIGNATURE-----

tomhoward.vcf
Description: Vcard