Re: The Policy(tm)

[Guido Draheim]

Peter Simons schrieb:
> Guido Draheim writes:
>
>
>  > 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.

The distinction for pre-allocation of fortran comes from the
distinct support for this area in the core autoconf package.
It is _not_ based on that `language exists` or some such.
Other lang specificas would probably go to `misc` or
`installed` or `system` or whatever and when there are
enough of them around _then_ is the time to think about
making up a new category of its own. IOW, fortran is a
bit special in this respect ;-)

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

Personally, I can stand the heat. I'd just say sorry and explain
that it is so much useful in other areas that it was justified
to accept it on a short-cut path - from real world this is known
as `late feature` that creeps into software projects even after
the official `feature freeze` deadline has past. Actually, I do
not want to have three-days to put up as another rule, it is
more like an archive maintainer to come around and `wooow, that
is a great one, let's put it thru as quickly as possible`, and
three-days is certainly the absolute minimum for an `ASAP` :-)=)

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

Not quite, but some `should` will make it anyway that anyone renames its
macros to the AX namespaces when there is a minimal chance to do so. And
I do not want to sound disrespectful firsthand when there are reasons that
a name in the AX namespace is not easy - it would make it that we never see
the macro in the first place and that we can not discuss the least with
the contributor if there are still ways to put it into the AX namespace.

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

okay 8-)


--- cheers, guido