Hi,
On Sat, 2007-10-27 at 22:41 +0200, ext Tim Teulings wrote: > Hmm, you never would get my applications ;-) I'm pretty sure that I > won't fulfill all the requirements. Maybe then rephrasing the sentence? This is not an official certification process, it is just a tool to get developers aware about the level of quality expected in extras. But. > For example being good at battery time is a tricky thing to test If this is true then we need to provide better documentation and tools to test/debug. At least the big issues should be not difficult to detect (you app is draining the battery in 24h even if running just in the background). I guess any developer can get some help by getting the packages in extras-testing and expressing the will to push them to extras. If a developer is not concerned at all about power management and hasn't got a clue about how his app is treating the battery, then his software shouldn't get so fast in extras. Indeed. We have got already real cases of a popular app getting all kinds of positive comments in one side, and then 'this battery sucks'-like threads here and there. Until someone is able to connect one app A with battery problems B. Developer A is then aware, gets feedback and implement fixes. Doing this before hitting extras instead of after makes a whole difference. > We would have some kind of (hopefully small) checklist that precisely > tells the potential application user what he can expect and what risks > he will take. All this sounds to testing quality and power user audience. Why don't put a little more effort in extras to have decent quality (not perfect, nobody is perfect), targeting all the tablet owners. > If an app kills a device (and the developer knows that) that > there is possibly already some criminal minimal mind behind - and then > the checkbox would not help either. Killing a device is a extreme case with a computable end result. Asking for "good quality" is different because both "good" and "quality" are very subjective terms. Quality Awareness just tries to define what are the quality levels expected in stable software for maemo. > OK, but to what benefit? To sue the developer ;-)? What is the real > effect of such a checkbox (see above)? Whoever is in charge of extras can push out to extras-testing a package based in a checklist the developer is supposed to know and has acknowledged. We can avoid the checkbox by having Quality Awareness and whatever else we decide (i.e. maemo packaging policy) as guidelines anyway as a reference, filing critical bugs against apps compromising the system and putting those critical bugs as obstacle that won't let you get to extras. As you see I'm only trying to make clear the principle, once the principles are clear we can discuss better the implementations. > I'm not involved in debian internals (I'm only an interested user), but > it looks like most of the time the human side is not that involved, Perhaps, but I guess in part becuse a lot of 'human side' is put when filtering who gets the rights of a Debian maintainer. Maybe I'm wrong, but if we set lower filters for access then perhaps we need more human reviewing and decisions. > Where do you see requirements for human interaction? Not sure. I only know that people will ask/rely on us Nokia if they don't find anybody behind extras. If extras will be ruled by the community people will expect community people there. As said, ultimately someone will need to have the right to say 'you get in / you go out'. Perhaps this someone can be a community message in the form of good/bad feedback and filed/fixed bugs and perhaps this in/out can be automated. But anyway, not that relevant at this point. We have still principles and implementations to discuss. -- Quim Gil - http://maemo.org _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
