Re: Some comments about the paper
On Tue, 28 Sep 2004, Miguel A. [ISO-8859-1] Arévalo wrote:
This point is interesting probably for most CDDs but I don't see why it
should be part of the CDD particular infraestructure. Almost every site-
wide Debian installation will need it so it must be part of Debian as a
whole (or GNOME/KDE/debian-menus systems in particular). It's just the
same as the GNOMElock/KDEkiosk facilities.
Well, there is nothing new for Debian. It completely exists as menu
builds menus for Gnomw and KDE. The only thing is that the cdd package
provides an easy interface for the maintainers of meta packages.
Of course it should be able for the CDDs to interact with these
facilities but I think these are not "central parts", or at least not be
on par with things like Metapackages, preseed, alternatives and so on.
What would you suggest to provide user menus in a CDD instead?
Anyway there is an error:
Strictly speaking it is not the best solution to conflate
a figuration mechanism, which users see with menus, with
access control, i.e. unix groups
Unix group are not access control oriented, they are an information or
name service (as in Network Information Service or Name Service Switch).
Access control services in Unix are a client of these Information/Name
services. So Unix Groups are, of course, the tool to use for User Roles.
That's an interesting point. I would love if you provide a diff to the
relevant section because I have to admit that I'm not so educated in these
issues that I'm able to find the precise formulation. Or would you like
to just remove this remark from the docs?
And so those other levels (Novice, etc.) should also be implemented as
Unix Groups.
There is no point in refusing to implement this also for user groups (if
somebody would like to do the work) but I think it is much easier to implement
for more powerful information services like LDAP which are really intended
to store this kind of information.
8.6 New way to distribute Debian
Here is my own proposal for these, I think every Debian developer/user
has his very own one:
* During "normal" debian developer cycle (from T0 to T0 + 1 year):
DD -> unstable -> testing
QA -> security -> stable
at T0 + 1 year:
freeze := stable
* During "freeze" ( from T0 + 1 year to T0 + 1.5 year ):
DD -> unstable -> testing
DD + QA -> freeze -> stable
at T0 + 1.5 years = T1:
stable := freeze
old-stable := stable (security for 6 months, already done by QA)
* Why?
Time based release cicle is good (this is of course my opinion) but
don't flame me on these, the scheme can be perfectly T0 + desired
features ready.
If I understand you right this is identical to the current release cycle
except that it is bound to a fixed time scale. Please correct me if I
understand your wrong. If I understand you right I see no special
relevance to the CDD issue because it concerns general Debian development.
Testing should be used by most Debian "advanced users"
Testing should get updated while freeze (this is one of the reasons for
people not using testing, with these scheme GNOME 2.8 will already be
part of testing at these very moment).
This in fact is really interesting and could enhance the release cycle
as it currently is a little bit - but also not connected to CDD (while
interesting anyway - but you should discuss this on debian-devel because
most people who are doing release work do not read debian-custom).
CDD should be part of Debian's main clicle (inside testing and stable)
so people don't get confused by CDD versions vs. Debian versions and so
on.
At least this is the current situation. I personally have no problems
with this but there might be reasons to have some CDDs with a different
release cycle. If you think of schools (debian-edu) a yearly release
cycle (with releases in early summer) might make perfectly sense.
6.5 [Proposed] List of requested configurable options
I think this could be a list of posibly configurable options on debian
packages, the CDDs that requested it, the bug id and the status.
What do you think ?
This is interesting but I personally see no resources to realize this.
It might eat extra time for developers to keep it up to date. Or are
you thinking about an interface to the BTS which automatically keeps
such kind of list up to date? This would be interesting but who will
spend the time to add extra tags to the BTS and writes this interface?
?.? [Weird proposal] Sample Custom Debian Distribution
The "hello world" of Custom Debian Distributions, a neutral, simple but
complete Debian testing derivative with sample packages, logos,
configurations etc.
It's not really weird and the basics are in /usr/share/doc/cdd-dev/examples.
If you think that it would increase the acceptance of cdd-dev I might think
about this but I hoped that the examples would be enough for the moment.
Alternatively I would offer to move the meta packages of any CDD to cdd-dev
for the (symbolic) price of having a free dinner (in the sense of free beer)
at the next conference I meet a responsible person. ;-)
And a question, are the Desktop and Enterprise Debian subprojects/CDD
alive or staled ?
Good question.
Kind regards
Andreas.
Reply to: