Re: Some comments about the paper
El mar, 28-09-2004 a las 13:51 +0200, Andreas Tille escribió:
> 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.
I'm not a debian-menu guru, but it seems that the cdd-menu stuff
rebuilds menus for every user, it would be better to have a set of
prebuilt menus for every role and make the menu-displaying app select
wich one to show.
>
> > 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?
Of course until upstream has these config options there will be the
necesity for a work-around like this. But I think that this should be
"carefully pushed upstream". I'm sure, for example, that Novell will be
very glad to have them on GNOME 2.10 for ZenWorks 7.0 for Linux.
But then again, take my comments on this with a grain of salt as
debian-menus are guru-magic at this point for me.
>
> > 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?
This paragraph can be completely left out of the document. and
the /etc/group referal changed to the apropiate libc function call (I
hope you are not parsing /etc/group, I'm migrating to nss_ldap at this
moment ;-)
>
> > 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.
>
Yep, but there is no problem with Unix Group.
> > 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
As free pointed freeze := testing
> >
> > * 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.
>
And the point of having a new freeze dist.
> > 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).
>
I'm sorry, I'm not brave enough to post this to debian-devel.
> > 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.
>
Yep, but I would always work on top of stable.
> > 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?
Well, I think that if we have it on the wiki, as a starting point, but
this will give a great visibility to the project. Adding a method to
select, for example, the gdm-greeter via an alternative is not that hard
for a newcomer. Why not try it on the wiki?, I volunteer to start it and
mantaining it until we know if it's usefull.
>
> > ?.? [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.
I'm pondering about starting a Corporate Debian CDD from the work done
on UserLinux ( :-S ) little by little on my free time.
Regards,
Miguel A. Arévalo
>
> Kind regards
>
> Andreas.
Reply to: