[maemo-developers] RFC: Proposal to solve multiple repository, poor QA situation

[From: Graham Cobb]

On Monday 14 January 2008 17:17:18 Andrew Flegg wrote:
> On Jan 14, 2008 4:52 PM, Marius Vollmer <marius.vollmer at nokia.com> wrote:
> > "ext David Hagood" <david.hagood at gmail.com> writes:
> > > May I suggest that the uploads consist of source, not pre-built
> > > binary .deb's?
> I agree with this. Having said that, I also think Neil's right in
> saying that an auto-builder's a lot more work. I'd be tempted to say
> that as an *initial* point (given that this is voluntary and not
> cutting off normal extras uploads) this should primarily be focused on
> the distribution of binary packages. If successful, it can be
> revisited.

I think Andrew's proposal is excellent.  Nokia have made it clear that they 
look to the "community" to solve the problems of managing package 
availability (Nokia do provide resources to help, like the extras and 
extras-devel repos).  Andrew's suggestion of a community of volunteers who 
help developers get their packages in extras whilst not doing away with the 
current scheme of allowing developers to request direct access is inspired -- 
it allows flexibility and avoids the volunteers being overloaded with very 
large package sets, often with complex dependencies for big applications 
(Canola, Gaim, GPE, etc.). 

Another part of the pragmatic approach is that, at least initially, 
submissions will have to be binary packages.  I believe that source should be 
required to be submitted as well even though there is no way at the moment to 
check that the supplied source really generates the supplied binaries.  That 
means that one day an autobuilder can be added.

One key to getting this successfully off the ground is that I think the focus 
should be on helping people do whatever is needed to release their package -- 
after all, we want to get away from multiple repositories for released 
software, not put roadblocks in people's way.  While it would be nice to have 
a Maemo policy manual and a "mintian" tool to check it, we can't get there 
from here -- there is just much too much work to do to get to that stage.

In particular, I am very much against the community trying to set guidelines 
on coding quality (such as "no warnings").  Personally I also dislike 
compiler warnings and try to eliminate them when I have a piece of code open 
for bug-fixing but a lot of Maemo applications are just ports of other things 
or are works-in-progress.  Reviewing code quality is just not a feasible goal 
at this time.

I am even fairly ambivalent to application quality.  I certainly think the 
volunteer should check that the supplied packages install.  They should check 
some minimal things (like not adding new application categories!).  They 
should probably even try to satisfy themselves that the application runs (can 
be started) and doesn't appear to do any damage (crashing the UI, for 
example).  But I don't think it is reasonable to ask them to check the 
application "works".  That is what bug reporting systems are for.

That brings me to a major missing piece...  If all these applications are 
going to go into extras, there needs to be some place to report bugs.  I can 
think of two good solutions for bug reporting:

1) Someone creates a bug reporting system for everything in extras.  It is 
well known and everyone is told about it.  Products would be created to 
correspond to the names of packages in extras.

The obvious downside of this is that it makes it easy to report bugs but no 
guarantee that anyone is listening!  Particularly if the upstream project has 
its own bug reporting system.

2) A new field is put in the debian control file to contain the URL of the bug 
reporting system for that package.  The AppMgr could have an option/button to 
visit the bug reporting URL for any package.

The two systems could even be combined: a big default bugzilla with packagers 
able to specify their own if they prefer.

Graham