[maemo-developers] Repositories mess: conclusions and actions

[From: Simon Pickering]

>> I still think the "assume it works unless people complain" would be the best
>> method, but if your rating app could also track dependencies that would
>
> I'm not against it personally, it is Nokia that stress the Quality aspect. I
> can understand this, since the Extras Repository is something "offcial". In
> understand Quill in that way, there should not be unstable software in it.

Yes, so this means we definitely need extras-devel as a first step then.

(This is probably repeating what others have said): Perhaps one way to 
deal with this is to use an automatic rating application (or simple bug 
filing) for applications which are placed in the extras-devel repo. If 
there are no bugs filed, or the ratings are positive, then it's 
promoted to the main extras repo where "normal" people will see it and 
install it. If there are any negative ratings/bugs at that point it's 
pushed back down into the extras-devel repo.

There's still the problem of getting enough people to actually rate an 
app (in a positive sense), or conversely to file bugs rather than just 
uninstalling it and moving on. The developers group is (and it is us 
who would presumably be the ones doing these ratings of things in the 
extras-devel repo) not all that large, and of that group not everyone 
will be interested in every app.

>> eliminate one of my points against this type of approach (that 
>> libraries may get
>> very few positive votes as people don't use them directly so don't 
>> know they are
>> being used).
>
> You mean: I have installed "CoolApp" and it worked, and since "CoolApp" uses
> "CoolLib", "CoolLib" should automatically be rated, too? I havn't planed
> that for an initial release.

Exactly.

> I currently show all packages that are in the
> group user/* (and by styleguide AFAIK that should not be a library) and
> where the user has not done any rating for the current version. Then I
> blindy try to push this rating into the (guessed from package name) project
> page.

That sounds like it may be difficult to get right in every case. I see 
why you'd want the extra (url/email) field in the .deb as you suggested 
in your email.

> This could work for dependent libraries, too. But the library should be in
> the application catalog (I havn't seen any).

Perhaps, perhaps not. If you can know the deps, then whether it appears 
is immaterial. You know it's been used, it probably worked. Not sure 
it's a clean-cut decision about the rating, but a good indication, and 
without this there won't be any ratings for libraries.

I must say that when I think of extras I do think of it containing lots 
of libraries that don't come as standard. This will save people lots of 
effort in developing/cross-compiling new apps. Therefore we do need to 
make sure that these "hidden" binaries are also rated/approved in some 
way.

> Another questoion (I already asked): Can/Should a user rerate an
> application, if there is a newer version (that would suggest different
> rating)?

I would say yes, as version changes affect what's being run 
(functionality and whether it was compiled correctly). The other thing 
to ask is whether we want to be rating (i.e. stars out of 5) or simply 
saying yes/no does it work?


To get back onto what to do with regards to repos now. We're all 
reasonably trustworthy, there's no reason to think we'd produce shoddy 
.debs on purpose, so why not (until the auto-builder/rating apps/etc. 
are ready) let people upload (on an individual basis) their .debs to 
the extras-devel repo. If there's no complaints about a package in some 
time period (2 weeks for example) then it's automatically pushed into 
extras.

I'm not sure how the "complaints" would best be handled (or how people 
could know where to complain about a given library). Perhaps leave it 
up to the authors to keep an eye on ITT/the mailing lists to see 
whether anything comes up?

Anyway, I'm sure that's gone round in circles and repeated what 
everyone else has said :)

Cheers,


Si