Module submissions: accept/reject checklist ?

[Duncan Gibson]

There has been a surge in module submissions in the past couple of months,
with several contributors, which is good. I've been testing locally where
possible before accepting them, but this takes a lot of time.

Christian Krause (wookietreiber) is a particularly prolific contributor
at the moment, but from what I gather, he is not your average user, and
is trying to build a very lean system with no X, the minimum of static
libraries, and with as many explicit optional_depends as possible in order
to slim down what is installed. That's all well and good for his own box.

    Just to be clear: this mail is not intended as an attack on him.
    In fact, once we clear up these guidelines, I wonder whether it
    wouldn't be better for him to be a dev and contribute directly!

I accepted the initial batch of --disable-static submissions, even though
these are hard-coded in the BUILD files, so everyone gets them whether they
want them or not. I am still not convinced that this is the right way to go.
There is now a 'binutils' submission in the queue with --disable-static,
and I'm very wary of accepting this because it's a pretty critical module,
hence this mail. Things that are discussed on #lunar tend to get forgotten.

Yesterday in #lunar, Ratler queried why I had accepted a submission that
simply removed a direct dependency that was also handled indirectly by
another dependency. That got me to thinking whether trying to optimise
the dependency tree was really worth the extra work, bearing in mind that
it can't really be tested properly without rebuilding from a pretty bare
system.

So, I would like to raise some questions, and canvas people's opinions,
with the idea of putting some submission guidelines on the wiki:

1: What do people think about the --disable-static changes? Is there a
   better way to achieve this that is not hard-coded and does not affect
   everyone?

2: Do we really care any more whether a module depends on both A and B
   if A already depends on B? Does it make that much difference to the
   dependency resolution times?

3. Do we really care about adding explicit optional_depends and other
   configuration options for all modules, or just where important?

   I happen to like the minimal system that Lunar uses where I can leave
   an installation to run unattended without it waiting all night for
   mquery and optional_depends questions to timeout. Or do we have to
   re-invent something like Gentoo's USE flags to get round this?


At the moment I have the following set of general guidelines in mind:

   In general, module submissions will probably be accepted if they:
     + introduce a new or missing module into the moonbase;
     + provide an updated version of a module;
     + provide updated download and website URLs;
     + provide missing dependencies required to build the module;
     + add BUILD options that enable a failing module to build.

   Module submissions are likely to be rejected if they:
     - do not follow the formatting guidelines given on the wiki;
     - fail to download sources correctly, or fail to build;
     - introduce system specific changes that not all users will want;
     - remove explicit dependencies in favour of implicit ones.

Any comments?

Duncan / engelsman