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
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
