[maemo-developers] Repositories mess: conclusions and actions

[From: Tim Teulings]

Hello!

IMHO this discussion is important, but needs some kick to start 
discussing real concrete solutions in more detail and to agree on 
suggested behavior. I would suggest to continue discussing but in the 
end of each of you mails define short statements, that summarize your 
idea and ideally are a "patch" to this or a similar list (especially my 
conclusion could be more concrete and shorter :-)) and especially agree 
or disagree explicitly on points already suggested to get a common opinion.

So I try to summarize and extract the key points already mentioned.

Problem
=======

- Nokia: There are many applications that would increase the wealth of
   our product, but me must guaranty
   + Quality (Quality)
   + Ease of use (Simplicity)
- Nokia: We want to centralize the development to just make things
   easier", "simpler" and add service - without compromising the open
   source idea. (Simplicity, centric)
- Nokia: We want to multiply by delegating task to the community
   (Scalability)
- Nokia: We must keep security in mind - nobody must be able to
   inject bad packages etc... (Security, Control)
- Nokia: We want to attract new developers and give them a guided
   testing bed (Iterative)
- User: There are a huge number of applications. Most of the
   applications would promote the devices and the platform, but it is
   difficult to
   + find the application (Locate)
   + judge, if the application has "quality" (Quality)
- Developer: Developers have problems to promote their software
  (Promote)
- Developer: It is difficult to assure that the application
   is installing and running well on all devices (Quality assurance)
- Developer: There are multiple platforms and I need to do building for
   them all manually (Build management).
- Developer: Not every developer is similar. The process must support
   + Garage
   + External projects but local packaging
   + External projects (Flexible)


Claims
======

This results in solving problems that can be described by the following 
key points (I admit that these are very common problems when working in 
the software development process ;-)): We need a process that...

- Defines Quality
- Assures Quality
- Is simple
- Is somewhat centric
- Is scalable
- Assures security and control over the process
- Is iterative for developers
- Helps user finding a application
- Helps promoting software
- Eases building packages
- Must be flexible regarding package sources

Comments
========

So some comments on some of the key topics.

Quality:
Quim quoted 
http://maemo.org/development/documentation/how-tos/4-x/quality_awareness.html 
but this is only a start. But Quim itself admits that there already 
software that is promoted while not fulfilling all criteria (and this is 
IMHO the right thing). So we need a better definition on quality like:
* Number of users installed must be significant.
* Number of bugs (=> Debian)
* Rating (as a soft criteria that signals requirement for further 
investigation). (=> Application Catalog)
There is also the question about who decides the quality? The process 
(=> Debian)? The user itself based on some numbers? Nokia?

To assure quality the process must react very quickly (more quickly like 
in Debian staging repositories).

Simple:
Simple for me means that it must be automatic. Things like auto 
building, evaluation of open tickets and application  catalog 
integration are IMHO a must.

Centric:
* Means that there is one official repository (which may be split into 
stable, testing..), one application catalog, one ticketing system. There 
is no way around this if we want to guarantee security and quality at 
the same time.

Scalable:
=> Automation and having a => group of people. At least part of the team 
should by non-Nokia "people".

Security and control:
So we need signing, secure process injection protocols and a clearly 
defined process. I thing Debian has a number of additional mechanism 
that could detect problems with Copyright and similar by scanning 
packages and differences between package versions etc...

Iterative:
We need staging repositories and a rating system that has more states 
than "good".

Finding Applications:
We have the application catalog which might need improvement but I see 
no other solution.

Promotion:
We could automatically generate high scores from the download numbers 
from the catalog and also from the rating. Promotion should be part of 
the catalog (and the home page). There is already something like that 
there but could of course bee improved.

Eases building/Flexible:
Tools, examples and Autobuilder/autoinstaller. fetching external 
repositories is IMHO no go, because of the security reasons mentioned by 
Nokia. Having an external project page myself, I see the problems but 
also see the problems supporting me. IMHO garage should be able to 
delegate parts of a project (web page, source repository) to external 
(trusted) resources. Building however cannot be externalized, so I still 
have to drop complete source packages into the process.

Conclusion
==========

For me this results in:
* Definition of the meaning quality in a community that consists of 
Nokia and the open source community.

* Implementing a Debian-like approach using autobuilder, staging 
repositories, possibly initial manual scanning of new packages (not 
package revisions), a central bug tracking system and a community 
consisting of Nokia and community people.

The difference would be:
* Much better integration of the application catalog and thus much
   better promotion features. Feedback from the catalog back into the
   quality system (Like "Create a bug for this application"-Links).
* Possibly much faster reaction on package problems (packages with major
   bugs will be kicked from "stable") and thus modified rules how a
   package walks through the staging repositories.
* Quality is not only defined based on bug tracking and license policy.

Infrastructure:
* Since Nokia holds most of the infrastructure I fear Nokia has the 
burden to supply the technical infrastructure while the community will 
support the daily work, the rating and the quality assurance.

OK, this mail got longer than expected. Hope this helps.

P.S.: Please do not go crazy on certain formulations. I know that there 
is Ubuntu and fedora etc.. besides debian... ;-)

-- 
Gruß...
        Tim