Alright, so we seem to agree in the general concepts. Let's go into details.
>The question is not the quality of the "Quality awareness document" >which likely could be improved. The question is, if such a >document is the right way to control quality? 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". 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'. >So what we then would need, is a in-queue >with new packages and every package has to be manually testes. >This would assure quality on a very high level, but likely >would not scale (and possibly would not work with a small >community). Agreed. >In this case I would still suggest using the three holy kings >(bug tracking, staged repository, application catalog) but at >this point would not concentrate on the holy guide but on the >holy process. Sounds good. >* 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. >* 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. >* We must find some clever way to get a response from the user >since we cannot trust "the masses" (our masses are not of >equal size then that of debian). >* For example: What about the program manager on the device >periodically > requests a rating from you for newly installed applications. >There will of course be a way to switch it off, and the the >notification must not violently jump into the middle of the >screen swinging its broadsword, disturbing my circles. 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. >* 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. >* 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? >This all requires some very fine, polity and well though out >additional applications and internal workflows but I think it Looks like a pretty feasible set of points to start working in the right direction. More criteria or is this enough? What about the human side? Who has the authority to say 'you get in', 'you go out'? Quim _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
