Re: The Policy(tm)

[Peter Simons]

Guido Draheim writes:

 >> If someone is submitting a completely new macro that duplicates
 >> existing functionality rather than submitting a fix to the
 >> existing one, it is only natural and appropriate that his
 >> submission should have to pass a high standard.

 > not better - different, with its own value not present in the other
 > one but perhaps the old one has another approach not present in the
 > new, so there is no `better` but `overlap` to some (minor or
 > larger) degree.

Why don't we agree on a compromise ... Correct me if I am wrong:

 (1) We _all_ agree that we should avoid having two macros in the
     archive that do the same thing.

 (2) If we receive a submission that provides overlapping
     functionality, the best solution would be to merge them into
     _one_ macro, that provides all of it.

 (3) In case that is not possible -- for whatever reason --, we need
     rules saying how to proceed.


Here we go:

    Overlapping Functionality

    No two macros in the archive should perform the same test. We do
    not wish to confuse (potentially inexperienced) Autoconf users by
    providing two competing macros for the same purpose.

    In case, a submission comes in that duplicates functionality of an
    existing macro (or a macro that is currently going through the
    submission procedure), the authors of the respective macros are
    informed, in the hope that they will be able to determine the best
    course of action:

     (1) They merge the functionality and submit an _update_ to the
         existing macro.

     (2) They agree to _replace_ the existing macro with the new
         submission, thereby obsoleting the original one.

    In the unfortunate case of the two authors being unable to agree,
    the submission procedure continues as follows.

     (1) Competing submissions:

         (a) The review period of _all_ competing macros will start
             from the scratch.

         (b) In a combined announcement for all competing macros, it
             will be clearly stated that only _one_ of the competing
             macros will be accepted into the archive.

         (c) Reviewers are allowed to vote in favor (or against) _all_
             competing macros; the votes are not restricted to one
             macro.

         (d) Of all macros with a majority of "accept" votes, the one
             with the greatest number of "accept" votes is accepted
             into the archive. All other competing macros are refused.

         (e) In case of a draw, the archive maintainers will do
             whatever they think is best. :-)

     (2) Submission competing with existing macro:

         (a) The review period of the submitted macro will start from
             the scratch.

         (b) In the announcement, it will be clearly stated that this
             macro will -- when accepted -- replace the macro
             currently in the archive.

         (c) If the macro receives a majority of "accept" votes, it
             will replace the macro currently in the archive, which is
             obsoleted.

Note that (1e) -- albeit somewhat humorous -- allows us to accept
_both_.

Peter