[maemo-developers] Repositories mess: conclusions and actions

[From: Tim Teulings]

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