Re: News about the macro archive

[Tom Howard]

Hi Peter,

> I think it is pretty impolite to reply to a private e-mail
> with a Cc to a public mailing list without even asking.

Sorry, I assumed it (you not cc'ing the mailing list) was an oversight
(happens to me all the time on another project).  My bad.  It won't
happen again.

> Now that it has happened, though, I might as well respond on
> the list too.
>
> You wrote:
>
>  > I've had 42 responses so far, out for about 60 that were
>  > sent out.
>
> That's more than I thought. I'm glad the support for
> different licenses is there now, though, because it sure
> looks like we won't reach 100%.

Yes, especially in the case of Mark Elbrecht.

>  >> @license AllPermissive
>
>  > I've actually been putting
>
>  > 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.
>
> Please don't do that, it will break the formatter. Please
> use:
>
>   @license AllPermissive
>

Sure I can, but can't I update the formatter instead? :D

>  > The reason for this is (as you pointed out) some people
>  > are using the macros directly from CVS, so we must ensure
>  > that they receive complete licence information with each
>  > file (i.e. either the all permissive statement or a more
>  > verbose GPL with exception statement).
>
> Yes, but editing the files manually isn't good enough.

Um..  sorry if this is a stupid question, but why not?

> We
> need license information in _all_ 340+ macros, so it has to
> be generated by a tool.

Once I've updated all the macros, there shouldn't be a problem, should
there?  I mean once the licence information is in there, it can be
changed (if we ever need to) easily using an script (awk, etc) and new
submissions can be checked (using an automated tool) before they accepted.

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

> If you add the license in verbatim in addition to the
> @license tag, then we will end up with the license _twice_
> in the macro.
>
> 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.

>  > Also, I noticed that the all permissive licence refers to
>  > a copyright statement, but currently there is no
>  > copyright statement in the files.
>
> This statement will also be generated automatically using
> the list of @author tags as copyright holders.
>

Sorry, another stupid question.  Why are you generating the m4 files for
release?  I mean I don't understand why you don't have the same m4 file
in CVS, tar.gz and on the website?  From what I've read so far on the
list (which isn't much, so it may be a skewed sample) most
users/contributors don't want generated m4 files, and this seams to be
the main sticking point with unifying the archive (which is ultimately
what everybody wants, isn't it?).

>  > Ideally it would be great for the average everyday user
>  > to be able to grab the code from cvs, and when they run
>  > make it would generate the docs for them.
>
> 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. My focus is on providing the
> archive, not on providing a solution that implements
> 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.  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.  If we had that as part of the release, then I could have
checked the output format  and made sure it worked before submitting,
saving you time.  I would have even submitted a patch to the Makefile,
so all you would have had to do was glimpse at the patch to make sure
there is nothing untoward (like editing files it shouldn't have, etc)
integrate the patch, run make and double check the html output.

>  > What do you think if we do something based on gendocs.pl
>  > [...]? Most users have perl installed (actually I think
>  > automake is written in perl), so it would mean that most
>  > users would be able to generate docs themselves.
>
> 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.

> What the
> Macro Archive really needs right now is not crazy HTML
> generation software, it is people who are willing to
> maintain the _content_. We have obsolete macros to mark, we
> should convert to the ax_ prefix policy, we should
> reevaluate the category assignments, etc. All this is much
> more important, IMHO.

I'm trying to help you maintain the content.

Cards on the table time.

My main goal at for the ac-archive is to achieve unification.  That is
my driving force in my (current and future) work in this project (I'm
hoping that by knowing my motivation, you find it easier to understand
my actions).  Now I fully understand and am willing to accept that you
have other primary motivations, and I'm more that willing to help you
achieve these (I don't expect to achieve my goals unless I help you with
yours) so long as they don't threaten unification (and don't worry, I
won't abandon the project once it unified.  I've got to make sure it
stays unified).

I'm already helping in terms of maintaining content by doing the licence
changes.  When that is done, I would love to add AX_OBSOLETE (once I
write it) to obsolete macros if that's cool with you (because I think it
would be really cool if the macros told their users that they are
obsolete, rather than just having something in the docs).  I'm also more
than happy to go through and replace

AC_DEFUN([AC_FOOBAR],[

# whatever is in here

])

with

AC_DEFUN([AX_FOOBAR],[

# whatever is in here

])

AC_DEFUN([AC_FOOBAR],[
AX_OBSOLETE([AC_FOOBAR],[SOMEDATE],[some message],[AX_FOOBAR])
AX_FOOBAR($1, $2, $3....)
])

to bring the naming scheme up to date (BTW that's the best way I can
think of doing it as it won't break stuff for existing users, but it
will let them know that they should change it).

When it boils down to it, tell me what you want and I'll make it happen,
so long as you are happy to move (it doesn't have to be fast) along the
path to unification.

>From what I understand, to make unification happen we need to no longer
generate the m4 files (the file is the same no matter where you see it,
cvs, the tar.gz the website or in the wild) and the build system
generates the docs (and does so on most platforms) and installs the m4
files and the docs.

What do you think?  Can we do this?  Does any of what I need (to make
unification happen) conflict with your needs?

Cheers,

--
Tom Howard

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x433B299A

tomhoward.vcf
Description: Vcard

signature.asc
Description: OpenPGP digital signature