[maemo-developers] Repositories mess: conclusions and actions

[From: Tim Teulings]

Hello!

> Depends. The "guide" (aka the Debian Policy Document, aka "policy")
> distinguishes between "musts" and "shoulds". Violations of "musts" are
> considered Release Critical bugs, violations of "shoulds" are non-RC
> bugs. Specific exceptions for specific packages have been made, when
> justified.

>> In the case we do not need a guide first, but the process will come   
>> first and then the guide will develop.                                

> Arg. No. The guide is critical. That doesn't mean the first release has
> to be perfect, and that it will not evolve, but you need guidelines.
> There's a lot of stuff in Debian policy that isn't directly related to
> good or bad, but simply choices. Consistency is an extremely valuable
> quality, and there's simply no way to encourage it (must less enforce
> it) without documented policy.

I was possibly not that clear in my formulations. I think that we may 
still share the same opinion.

IMHO we are talking about two different aspects of such a "guide".

The first one - the one that I think you mean (and that I think is 
important and must be agreed on to initiate the process) - is the guide 
that defines the process. Of course an important part of the process is 
for example packaging. You a right in that we can copy most of such 
guides from debian. However it is likely that we have to modify this. 
For example we may need some additional headers for the in parallel 
discussed bug tracking client application. So here we agree :-)

If you look at the said guide Quim mentioned however this guide does not 
define the process and the framing rules for the extra repository and 
its uses, but is is a (in future :-)) detailed list of test cases to 
determinate the quality of an application (of course Quim might have 
planed something different, but this is my interpolation into 
thefuture). Part of it is packaging (which overlaps with the rules) but 
some part might develop in a check list for a tester. Such checklist is 
not required now, because the process does hopefully handle quality 
without explicit quality assurance by a trusted person. We currently 
would require only general requirements (which could be part of the 
guide) but again the process will find its own (possibly surprising) 
requirements - the requirements of the people that install and vote. For 
example we may find out,that fine power management is not important to 
(wild guess) 50% of the people. So who are we to forbid battery killing 
applications their march into the repository (hmm, however the other 50% 
may like to know...).

> And while there's quite a lot in Debian Policy that may not apply, or
> needs to be reconsidered for the tablet environment, there's a lot
> that could be adopted as is. It's certainly better than starting from
> scratch. And gratuitous differences should be avoided like the plague.

Totally agree. For example the staging stuff and the packaging system 
seem to have general agreement by nearly all participants in this 
discussion.

> You'll never ensure this. What you can hope is that packages that move
> from whatever-we-call-unstable to whatever-we-call-testing have had at

That process is completely OK and I never spoke against that. However I 
think we must tweak it a little bit for our purposes and framing conditions:
* We have a much smaller user base. So we must make feedback as easy as 
possible.
* We have mostly GUI applications which may make things easier in some 
situations.
* We have that nice application catalog :-)
* Or desktop is much simpler and thus we can better integrate our 
process into the desktop.

> I also want to point out the classic "the perfect is enemy of the
> good enough". The processes and documents can, and should, evolve as
[...]

Security, quality, central approach - all part oft my initial claims :-)

-- 
Gruß...
        Tim