Masterplan

[Peter Simons]

I would like to propose applying proper project management techniques
to this effort, to make sure that we don't run into different
directions or get side-tracked in non-essential issues all the time.

The new infrastructure works and I have duplicated the old
functionality with the new software. So far I have been on safe ground
all the time. But from now on, everything we do should be
well-considered, or we'll waste time doing stuff that we think is
cool, but does not benefit the users.

On the main page of the archive,

    http://www.gnu.org/software/ac-archive/

there is a "masterplan", which lists the topics that we should discuss
and decide about the way to go on each of them. (Of course, the list
is not necessarily complete. If anyone has any idea, just fire away.)

In my opinion, we should tackle this from the user's perspective. What
does the user want? I would list the following objectives:

 (1) He has a concrete problem he wants to solve, and he is trying to
     find the macro that does it for him.

 (2) He wants the macro to _work_.

We can tender to these requirements through two enhancements: A better
category system and a review process for submissions.

As for the categories, I suggested:

    C Support
    C++ Support
    Java Support
    Cross Compilation
    Installed Packages
    System Headers
    System Utilities
    Build Infrastructure
    Miscellaneous

Is that alright?


Concerning the review process, Braden McDaniel had several ideas how
this could be accomplished, so I'll just quote them from his e-mail
(after he gave me permission to do so):

 | I think providing some basic quality control should be part of the
 | role of the maintainer.
 |
 | [...]
 |
 | Perhaps it would be useful to institute some sort of semi-formal
 | peer review process? For instance, someone submits a macro or a set
 | of interrelated macros to you, and you make them available in a
 | "holding pen". A message is sent to <address@hidden> announcing
 | the submission and requesting comments. After a reasonable period
 | (2 weeks, perhaps), the macros are either accepted or rejected.

He furthermore argued:

 | [...] as someone new to autoconf, I was unconfident of my own
 | ability to diagnose problems in someone else's macro. I figured
 | that if it was good enough to be in the archive, odds were that I
 | was misusing it. Two years and lots more autoconf experience later,
 | I know that perception to be naive and misguided. But I think it is
 | a perception that a number of autoconf neophytes probably have
 | today.

And:

 | Another wish of mine is [...]: Besides a basic provision of
 | quality, it would be nice if the macros in the archive could
 | promote a Right way of doing things. For instance, with regard to
 | Java, the archive currently provides more than one way to skin the
 | cat. I'd prefer to see a single solution. [...] I think providing
 | multiple ways to do the same thing is another way the archive can
 | confuse new autoconf users.

Installing such a "holding pen" area (albeit one that is publicly
available) would not be that complicated. Unless significant problems
are pointed out with the macro, it is accepted and goes into the
"official part" of the archive. I like the idea very much.

Peter