Hello! > Alright, what about leaving the role of this document in a checkbox developers > check in order to get upload rights to extras, à la terms & > conditions. Something like "I'm aware of the maemo Quality Awareness criteria and > I have tested my applications against them before uploading them to > extras".
Hmm, you never would get my applications ;-) I'm pretty sure that I won't fulfill all the requirements. For example being good at battery time is a tricky thing to test (it possibly that my applications do not stop cursor blink when the device tries to sleep (I'm not using Gtk)). and I'm sure that for my application that isn't really a problem. So possibly there should be more than one checkbox so that I can say: * Stable * Installs well * Deinstalls without problems and does not leave anything on the device. * ...but possibly does not handle power management that well. 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. But thinks are getting possibly too complex in that direction. I have visions of a number of strange symbols behind each application name in the application catalog (like a battery for power management aware applications and similar) and some users might get information overflow and are in the end not able to make the right decision. Btw., (de)installation checking can be automatized (much better than testing it manually). Somebody already has some script for that. That should be definitely part of the solution! So that part fo the checlist could already be dropped. Does that really lead us in the right direction? What realm harm could be avoided by that checkbox? I think that checkbox can only avoid installation harm that possibly can also be avoided be automatic testing. 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. > Of course developers might check the box after having gone through the 100%, > 50% or 0% of cases and his software might or might not contain major bugs, > but at least nobody can say - 'sorry guys, I didn't know my app could brick the > device'. OK, but to what benefit? To sue the developer ;-)? What is the real effect of such a checkbox (see above)? >> * A packages does not get into the stable repository if its >> bugs are "over the limit" (and debian has a precise definition >> for "limit" :-)). > > Any requirement about where these bugs should be filed? The minimum > requirement would be a public bug tracking system and responsiveness from the > developers. I already mentioned a central bug tracking system for the whole system or at least for all applications in the bug tracking system. So that would be OK for me. >> * 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. > > http://maemo.org/downloads can serve well this purpose. That I also already proposed. Agreed, too. [...] >> * For example: What about the program manager on the device >> periodically >> requests a rating from you for newly installed applications. [...] > We might discuss about this feature in the Application Manager. However, > if you find this idea useful it would be faster and probably better to > start with an installable 3rd party application covering this > functionality and targeted to maemo power users. I would love to implement such stuff (and I'm sure I could, if there are the necessary interfaces) :-)). But since I have my own GUI library (so the result would not be a GTK application) and no knowledge of apt I would step aside for somebody else ;-) I also think this would require some nice interface in the applications manager, else somebody has to fiddle with faking SSL HTTP requests :-/ >> * 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). > > Good point. See Gnome (and Windows Vista :-/). >> * Also we need a very easy way to get bug reports (and feature >> requests) directly from the device into the bug tracking system. > > It is clear the convenience of having an automated way to send crash reports > with traces, but what else would be needed other than that? Do you > mean an option inside the application saving you the effort to find the > right bugtracker/product/component? I would not propose in-application solutions - simply because not all people use Gtk for development (especially me;-)). Collecting crashes is technically solved by the application starter process (wait for SIGCHLD). It would make sense to integrate (or at least base it on information from) this in the application manager, because he can read the necessary bugtracker/product/component stuff from the package. And if I know the path of the binary, I can reverse lookup via the package repository the name of the package and then again the bug tracking information. > What about the human side? Who has the authority to say 'you get in', 'you go > out'? > Quim 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, simply because the process handles such stuff automatically. This is not a bad thing, because that at least is a fair solution!? In fact the user decides by downloading, bug tracking and rating. Human interaction should only be required for: * Initial package checking (FTP-Master like) * Highest escalation level (application has major bugs, hangs around for a long time in testing, no new updates for along time, developer does not react). Escalation, kicking out packages that never got downloaded and similar stuff would be primary based on rules. Where do you see requirements for human interaction? -- Gruß... Tim _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
