This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools.
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
