Module submissions: accept/reject checklist ?

[Stefan Wold]

On Tue, 2011-04-19 at 21:35 +0200, Duncan Gibson wrote:
> 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.
> 

We need to streamline the process of accepting submissions. Right now I
don't believe all developers know how to use the script to accept/deny
stuff in the queue. But it's nice to see that the community is alive!

> 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 think he proved him self by now. If he feel up to the task I see no
problem giving him dev-status.


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

We should make this a global option, but I'm not so sure all configure
scripts have this option which might cause it to fail. Once investigated
it would be pretty easy to implement that feature. The same could also
be done for documentation, I have some ideas how it could be implemented
on a module level.


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

I'm comming from a world where I believe all modules should have the
complete set of dependencies. It helps a lot when you really need to
rebuild a module with a certain dependency. In the future I want to
implement a TRIGGER file instead of the need to run lin -c module(s)
from POST_INSTALL, it would then be possible to trigger a rebuild of all
modules depending on X or if an installed module has a version lower
than Y etc etc.

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

This is one of the awesome aspects of lunar, the option to tailor your
own system. We should _always_ aim for optional dependencies and
configuration questions where possible. For the unattended part we could
probably tune the default timeout to be a bit lower. I'm open for other
suggestions as well regarding the timeout. USE flags are out of the
question ;)

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

Good guidelines.

-- 
Sincerely
Stefan Wold
Lunar Linux developer 
PGP public key 9FF9A9CF (Key roll over - Old key: 6E810F05) 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20110420/df52a6e3/attachment.bin>