a home for comps @books group

[Jens-Ulrik Petersen]

So I start a rawhide install and decide to browse (customize)
the package groups...

I see an uncategorized group standing out - turns out to be
a new @books group which currently contains 3 devel books...

Then I remember fedora-security-guide-en_US (which doesn't
really fit with the devel books).

But there is the string/translation freeze so I hesitate
to add a new Documentation category for F12...
(maybe/probably we should for F13?).

It seems most of the fedora-docs are published on the web
so fedora-security-guide-en_US seems a bit lonely
(probably also since current fedora publican still doesn't
support the right package naming-scheme for fedora [1]).

Anyway for F12 the options for @books seem to be:

a) add @books to the Development category,
(fits the 3 current opensource devel books there)
b) add to Base category - less obvious IMHO; or
c) break the string freeze and add a Documentation
or a Content category?

Or anyone have a better way?

Probably more thought is needed on groups later:
ie it might be better to have separate groups for
devel and sysadmin type books later when more
are packaged.  But that shouldn't be a problem
once they have their own category, or devel-books
could be in Development, etc.  A "Content"
category would also allow other kinds of free content
than just books and documentation.

Jens

[1] publican-1.0 should be able to create
unversioned package names
https://bugzilla.redhat.com/show_bug.cgi?id=478950

[Chris Curran]

Jens Petersen wrote:
>  So I start a rawhide install and decide to browse (customize)
>  the package groups...
>
>  I see an uncategorized group standing out - turns out to be
>  a new @books group which currently contains 3 devel books...
>
>  Then I remember fedora-security-guide-en_US (which doesn't
>  really fit with the devel books).
>
>  But there is the string/translation freeze so I hesitate
>  to add a new Documentation category for F12...
>  (maybe/probably we should for F13?).
>
>  It seems most of the fedora-docs are published on the web
>  so fedora-security-guide-en_US seems a bit lonely
>  (probably also since current fedora publican still doesn't
>  support the right package naming-scheme for fedora [1]).
>
>     
Desktop is a goal. Ebooks are a longer term goal (which could also be 
distributed with this method).
>  Anyway for F12 the options for @books seem to be:
>
>  a) add @books to the Development category,
>  (fits the 3 current opensource devel books there)
>     
I think this is a good solution. There is no point breaking string 
freeze if the books are already deprecated.
>  b) add to Base category - less obvious IMHO; or
>     
Base would not be a good place for it in my view. Many use the Base 
group for minimal installs and it would annoy me if no one else to have 
docs there.
>  c) break the string freeze and add a Documentation
>  or a Content category?
>
>  Or anyone have a better way?
>
>  Probably more thought is needed on groups later:
>  ie it might be better to have separate groups for
>  devel and sysadmin type books later when more
>  are packaged.  But that shouldn't be a problem
>  once they have their own category, or devel-books
>  could be in Development, etc.  A "Content"
>  category would also allow other kinds of free content
>  than just books and documentation.
>
>     
I think it is wrong to have split groups for different audiences. There 
is always some crossover between audiences and with larger books this 
quickly becomes a very, very difficult question (as to whether to split 
the book or chuck it somewhere with a less than perfect fit). All books 
should be in one package group (regardless of whether there are 400 
books or 4). Most people don't use groupinstall and those that do 
usually want everything (hence why they used it).


Chris


-- 
Chris Curran 
Content Author II
Phone: [phone] (UTC+10)
193 North Quay, Brisbane, Australia.
Red Hat, Inc.

[Bill Nottingham]

Jens Petersen (petersen(a)redhat.com) said: 
>  a) add @books to the Development category,
>  (fits the 3 current opensource devel books there)
>  b) add to Base category - less obvious IMHO; or
>  c) break the string freeze and add a Documentation
>  or a Content category?
>  
>  Or anyone have a better way? 
Adding them to Development for now seems best.

Bill