Module submissions: accept/reject checklist ?

[Dennis Veatch]

On Wednesday, April 20, 2011 01:34:52 AM Stefan Wold wrote:
> 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!

It is overly complicated from my view. Yes I could set things up as the wiki 
suggests but why bother. Just modify the review script so I can;

1. use my local moonbase master or test branch via ssh
2. run the script specifing the patch name
3. patch the local module, lin it, accept or not (if not then revert the local 
change) 
4. if accepted update master on doppio giving credit
5. remove from queue

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

Agreed.

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

I have a sense there are perhaps a handful of modules that have fake configure 
scripts. Cinelerra is one that comes to mind who top level script kicks off 
others because it includes other apps/libs that have real ones.

For those modules that have fake configure scripts there would be a BUILD 
anyway (for the most part) because of the additional fiddling needed. Right now 
I don't think it would be a problem with a global disable static. Perhaps 
adding that to default_build and default_config functions.

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

I agree here. I have always felt if it is a dependency then it should be 
listed. For someone new and they looked at the DEPENDS of the kde4 profile, 
they would not know that kdepim4 depends on kdepim4-runtime. 

> 
> > 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 ;)
> 

No USE flags period. If I wanted to go down that road then I would be using 
another distro. 

I don't see where the timeouts are that big a deal. Just change your prompt 
delay from the default of 150.

There are some modules, mainly Perl that will need some tweaking like xawtv 
and some others that wait for user input outside of lsh. I fixed one perl 
module (Net-DNS) with that issue. Fortuneately it was easy enough.

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

____________________________
Dennis `stumbles` Veatch
Lunar Linux Developer
http://www.lunar-linux.org/