[maemo-developers] Repositories mess: conclusions and actions

[From: Krischan Keitsch]

Am Donnerstag, 25. Oktober 2007 schrieb 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.ht
>ml 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... ;-)

Hi Tim

That really is a long mail ;-)
What you describe sounds like the ultimate solution. In my option it is okay 
to think about the how-it-should-be state. This also points out a direction 
where the discussion and later the process could possibly move to. I also 
agree with you on the key aspects such as simplicity, security and 
flexability.

Where you come from the top I look at it in smaller steps (pragmatic approach) 
to improve things. I would build on the infrastructure that is there already:
 
Prototypes and early betas could reside in Garage and move up to 
Extras-testing when the time is ready (product owner asks for permission).

If you (as a developer) want your application to move ahead to Extras then the 
app must have a quality mark above certain value. The comunity (maemo 
members, Nokia and the rest of us) votes on different attributes (usability, 
stability, integration, ...) at maemo-Downloads.

This should not lead to a complete redesign of the infrastructure. It should 
rather improves what is there already. Steady evolution instead of a brake.

Regards Krischan

PS: It is damn late already.