El Sun, Jul 04, 2004 at 09:04:52AM +0200, Andreas Tille va escriure: > On Sat, 3 Jul 2004, Otavio Salvador wrote: > > > IMHO code and docs NEED be relased together. > > > > If we change some issue in code, this should be updated in docs too. > In principle yes. > In practice I do not really like to increase the version number of the > docs after each bug fixed in the code (and I expect more of these bugs > once people start using it more ;-) ). > On the other hand increasing the version number of the code if nothing > has changed only because some paragraphs are added to the docs is not > really a good idea. Or holding back version 1.0 because the docs are > not really finished seems to be a good thing. > > I would like to fix this by just including a sentence in the introduction > which says something like: > > This doc covers the cdd package version x.y. Well, I know I'm mixing things, but more or less this is what we want for the L10N support we are planning, a way of having data packages (documentation, icons, whatever) related to *binary* packages (*binary* here means that it is something that has to be executed, not that they have to be compiled programs, of course) with different versions ... the idea comes from the problems we see when somebody asks for package updates related only to L10N and the way our current stable distributions handles updates; we only have security updates, but I see no reason why L10N updates can't be done also (except in very special cases, a new or improved translation has zero influence in the security of a package and makes it a lot better for local users). > > Sorry but I don't used yet the menu features of CDD and didn't > > understand well the reason to provide the docs. > The docs provide information about packages which come without a menu > for certain reason (not because the maintainer forgot it - this should > just trigger a bug report). Hmmm, I don't really understand the need for this docs section ... I thought that all important packages should have a menu entry; if a package doesn't has it, how is the user supposed to find it? (I'm assuming here that the menu system is for CDD users that doesn't read manuals nor documentation, of course ;) > > IMHO, the menu structure possible can be changed to allow a more > > featureful use like: > > > > etc/ > > cdd/ > > helpers/ > > menu/ > > docs/ > No this makes no sense. Just read > > http://people.debian.org/~tille/cdd/ch-technology.en.html#s-any-dependency--menus > > (and tell me if this not easily understandable ;-) ). OK, reading this I understand that what you want is to have a menu entry that, instead of executing an application, opens a documentation viewer with your docs ... If that is what you want I'll put this docs in /usr/share/cdd/CDDNAME/pkgdocs/ and add menu entries for each document that open it in the preferred viewer. I've used the name *pkgdocs* to avoid using the *docs* name alone, I agree with you in that *docs* is confusing. > > In mean time, we probably have more helpers to user like configuration > > tools and like so why not include it on helpers directory? > Well, we have further helpers but I now wonder if it makes really sense to > put the menu entries in /etc. The original idea was that these menu items > could be changes by local administrators. But in principle they are in > the same category as menu entries under /usr/lib/menu. I wonder if these > entries should be moved to /usr/lib/cdd/menu. I think so, what I'll try to do is having something in /etc that lets the sysadmin customize the menus, maybe simply using /usr/lib/cdd/menu and his local changes to generate the real menus. > I just would like to repeat my question: Do you think that the user menu > idea is not worth the effort? This is a real question and I would just like > to know whether I'm trapped in a certain thinking caused by some local > requirements. IMHO our target users need an adapted menu and I would like > to hear your opinion in your environment. In our environment the customized user menus are also a requirement; in fact we plan to have our menu included in the Debian one, as you are doing now, and also modify the main menu to use a CDD only menu (we don't want some user roles to see the full set of programs and we will probably implement a Kiosk user role based on GNOME, were this menu is going to be the only way to launch programs). Actually our problem is that, as with other things, we are working first in the quick solution (our menus are only going to be used in GNOME, so we are studying the gconf issues and using '.desktop' entries) to be able to solve the urgent ... showing the actual package selections in their right places. Once we have it working we will try to use the cdd system to generate the menus, modifying or adding things if needed. -- Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/> Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature