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. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
