[maemo-developers] Repositories mess: conclusions and actions

[From: Tim Teulings]

Hello!

>> - Nokia: We want to centralize the development to just make things
>>    easier", "simpler" and add service - without compromising the open
>>    source idea. (Simplicity, centric)

> Centralization doesn't compete with 'the open source idea'. We are

I did meant that (it was meant exactly they way you define it, too). 
Centralisation can mean "control" (upto totalitraianism). In the context 
Nokia IMHO explicitly stated that they want control for good and want to 
take control together with "the community".

> proposing it not because we are Nokia but because we are running maemo
> on top of GNU/Linux and .deb packages. Just look at how your preferred
> open source software distribution is organized, it is almost a paradox
> that most if not all of them are in fact more centralized than maemo. 

Right. It sound easier to take part at the "extras" process than to get 
a debian developer ;-) For small communities it is important to be open.

>> - Nokia: We want to multiply by delegating task to the community
>>    (Scalability)
> 
> Delegating is not accurate enough. We want to empower the community to
> push and promote the software they think is good enough for that.

OK.

>> * Definition of the meaning quality in a community that consists of 
>> Nokia and the open source community.
> 
> The Quality Awareness document is open to improvements and
> contributions. We don't want/need to have different docs to define &
> measure quality, so whatever idea you have please check it against the
> current doc and suggest improvements to it.

The question is not the quality of the "Quality awareness document" 
which likely could be improved. The question is, if such a document is 
the right way to control quality?

How would we guarantee the quality defined by this document? This can 
only be done by manual test (at least definitely if we would further 
improve the document ;-)). The test have to be done by the developer 
first. However since you cannot (always) trust the developer, somebody 
has to test the application again. So what we then would need, is a 
in-queue with new packages and every package has to be manually testes. 
This would assure quality on a very high level, but likely would not 
scale (and possibly would not work with a small community). Note that 
debian FTP master as far as I know only check license stuff and similar 
- they do not check the application itself (and they are sometimes still 
slow (for whatever reasons)). This kind of quality assurance is the 
classic way for companies. I doubt this is the right way to go.

The Linux community distributions handle quality differently. They use 
same small initial checks and then a staged repository. Debian still has 
a policy and style guides and similar and tries to do automatic checks 
that guarantee compliance with these guides. However most the actual 
"crashes" bugs are notices after the software initially entered the 
repository. In this case a "guide" is still good (and you always get 
your bugs fixes if it violates the guide ;-)) but quality get a much 
more diffuse meaning. I'm sure that debian has a number of applications, 
that don't fulfill all the requirement in the guide. In the case we do 
not need a guide first, but the process will come first and then the 
guide will develop. The problem is: How to assure that still no 
important bug (that for example kills my device) gets through.

In this case I would still suggest using the three holy kings (bug 
tracking, staged repository, application catalog) but at this point 
would not concentrate on the holy guide but on the holy process.

For a small community with with high quality requirements (and debian 
has also high requirements for their community is bigger, so they have a 
very high trust that no bug get trough the process) I would still suggest:
* A packages does not get into the stable repository if its bugs are 
"over the limit" (and debian has a precise definition for "limit" :-)).
* A packages does not get into the stable extras repository if there are 
not at least X successful installation and "behavior" reports.
* A package needs some average ranking to enter the stable repository.
* We must find some clever way to get a response from the user since we 
cannot trust "the masses" (our masses are not of equal size then that of 
debian).
* For example: What about the program manager on the device periodically 
  requests a rating from you for newly installed applications. There 
will of course be a way to switch it off, and the the notification must 
not violently jump into the middle of the screen swinging its 
broadsword, disturbing my circles.
* Also it might be very effective to collect and submit regular crash 
reports from the device to the application catalog (of course delivery 
must again be optional and not the microsoft way).
* Also we need a very easy way to get bug reports (and feature requests) 
directly from the device into the bug tracking system.

This all requires some very fine, polity and well though out additional 
applications and internal workflows but I think it could be the better 
approach than getting the "guide" ready and then either hire additional 
testers at Nokia or get 10 community people to do stupefying (but not 
stupid!) tests. And it likely scales better ;-)

-- 
Gruß...
        Tim