Re: The Policy(tm)

[Peter Simons]

Guido Draheim writes:

 > a\ We accept all the macros that go beyond base autoconf project,
 > possibly for being to specific or used in just some corners
 > of software development - the GNU Autoconf Macro Archive is the
 > right place to hold all of them.

If that is alright, I'd rather add this text to the to-be-written
front-page of the archive. The policy document should IMHO be as short
as possible.


 > actually, all macros must be GPL-compatible [...]

Alright. I'll change the policy to accept GPL-compatible licenses as
well. But before I do, I'd like to throw three more points into the
discussion to get your opinion on those.

If we allow different licenses ...

 - ... every macro must state the license it's under in the submission
   format. (This would arguably be somewhat simple with the XML format
   but not with the legacy format.) Meaning, that the maintainers --
   we(!) -- have to check it, correct misspelled keywords, etc.

 - ... the license text must be included in the tar.gz archive as
   well, whereas now, I just have _one_ license file in it and state
   "this one applies to all of them".

 - ... we must have an answer for submitters who want to release their
   macro under the "Megalomanie Institute of Slowly and Painfully
   Working out the Surprisingly Obvious Copyleft License" -- but alas,
   it is not listed on the GNU site, even though it _looks_ to
   compatible with the GPL.

If you feel that this isn't a problem, well, then it probably isn't
and I'll tag along. :-)


 > A `fortran` category would be good as well ;-)

I don't mind at all, Fortran is cool. :-) I just wonder:

 - Should we add new categories when a macro, which would go into
   them, actually appears, or

 - should we add them right away and hope that something will come
   along?

I am asking because there are quite a few other categories that we
_might_ have (Objective C, Perl, Phython, etc.), but we do not have
any macro for them. At least none that I know of.


 > Hmmm, I would like to weaken this policy a bit - some macros are
 > good enough to get through a shortcut-path.

Personally, I don't like non-determinism. I would not like to make
_any_ exceptions, because this is inherently unfair.

Let's say we get a submission that looks good, we short-cut it, and
two days after it has been accepted into the archive, someone speaks
up and says: "This macro breaks completely with this compiler, that
shell, whatever OS, etc." Then we'll look really, really stupid.

If we had played it by the book, then we couldn't have helped it. If
we go for the short-cut, we messed up.


 >> 1. Macro names must begin with the prefix AX_ [...]

 > s/must/should/

I thought we had (all) agreed on that before and considered it to be a
good idea? Is there a case in which a prefix but AX_ would be useful?


 > swap 3./4. in the text?

Yup, I'll do that ASAP.


 >> Releases
 >> [...]

 > s/ On the 1st day / Usually at the end of /

Hmm, good point. I'll have to think about that ... Any other opinions?


 > perhaps make it at two-month intervals if needs to be regular.

It doesn't need to be regular. We can as well release whenever we want
to. I'd just prefer regular releases because then we can automate the
procedure and don't have to worry about it. The monthly figure comes
out of thin air; I'm happy with whatever we'll do. :-)

Peter