Module submissions: accept/reject checklist ?

[wookietreiber]

Hey *,

On Tue, Apr 19, 2011 at 09:35:52PM +0200, Duncan Gibson wrote:
> 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.

as I have suggested before, I suggest it here again: why don't we include a
lunar option, where users can specify by themselves whether they want to have

1. static only,
2. shared only or
3. both,

so everyone can choose AND will not get asked this stuff while the module is
building (I don't know whether there are CONFIGURE mqueries for static/shared).

Same goes for the documentation stuff. I've discovered on several occasions a
modules size being 60 MB and 58 MB of them were documentation stuff only actual
developers of that module need ... see submission queue -- there are some
modules where this is the case. So why not include a global option for docs as
well? (Of course there should be an option for lin, e.g. --docs, which has to
be saved somewhere so the default behaviour can be overridden)

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

You're propably right -- better to discard binutils, although I haven't had
any problems, but this is a case where its propably best to have at least a
static build.

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

See above.

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

Thanks for the work on this set. Is it in the wiki / would you please put it
there, if not?

Best regards
Christian Krause aka wookietreiber