[maemo-developers] Repositories mess: conclusions and actions

[From: Kees Jongenburger]

> >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).

I think that a lot should really "just" be automated and the process should
really be about the quality of the packaging anyway
Questions that we should think of are:
-What happens when the package is installed on a clean device
-Was there a menu item created
-Does it not contain documentation
...

> >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.
Please consider mud or a mud like approach.
What the project is missing are endorsements and hardware.
http://mud-builder.garage.maemo.org/index.php

> >* 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.

The packaging / repository team should not play police to much. how is
a bug to be discovered if nobody used the package. I think that the
current /downloads is a good step in the right direction(but still far
away of what I would like).

On a personal level I have no problems with having many repositories
in my package management system. I just don't like them to be on
different hosts
One repository per garage project would be just fine by 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.
it really sounds like a lot of software to create. I maintained
something similar
at one point to keep track j2me device capabilities .

> >* 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.

I think it is just the other way around. For a "normal" user I would
say that it is already hard enough to create a single package and you
can not expect them to test this package on different plafroms etc.
Therefor this information is even more relevant to them...

I sincerely think that this is where the community can and must kick in.
We are talking about helping users and developers.

Starting from the current situations (sbox1 and the deb based distro)
and looking at the roadmap it looks like we are going to stay with
this scheme for a while(the same old gcc etc).

An other idea would be to open up the "real" distro to allow libs to
be placed there.
The nice thing about that would be that there is already a QA process on that

>
> >* 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.

consider http://bugs.maemo.org/show_bug.cgi?id=1563


>
> >* 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.
It really does not sound sexy :p