[Fwd: Re: making Fedora Documentation Project a stand-alone Fedora Product]

[Karsten Wade]

On Mon, 2005-07-11 at 09:38 -0400, Paul W. Frields wrote:
> On Mon, 2005-07-11 at 10:30 +0100, Stuart Ellis wrote:

> > Since we may be maintaining docs for packages for Core and Extras (some
> > documents might reference packages from both), I guess the best
> > component prefix would be just "fed-", if we use one. 
> 
> Aren't these components all under the "Fedora Documentation" product?
> If so, isn't such a component prefix redundant?  After all, the "Fedora
> Core" or "Fedora Extras" products don't call their components
> "fed-kernel" or "fed-yum-utils."  I can't see the FDP ever doing
> anything *other* than Fedora docs, but if my logic is flawed, someone
> please beat me with the cluestick.

I didn't get an answer about globally unique IDs for components, so I'm
going to assume they must be unique.  

I think we don't *have* to use a prefix,  but if we do need for an
occasional component to be clear, how about "fdp-*"?

> > > So, should we have components that match 1:1 with the names in CVS?
> > > 
> > > Seems OK to me. :)
> > 
> > I like simple :).  We'll probably need something for toolchain
> > bugs/requests as well, separate from docs-common, but perhaps that
> > should just be a tracker bug (as it is now), rather than a component.

We can have a component for 'docs-toolchain' or similar.

> I was going to say that "docs-common" needed a component, thanks for
> remembering for me!

Aye.

> > Odd idea: Should tracker bugs live in a separate component, since they
> > potentially link to bugs in multiple components ?
> 
> It should be easy to simply have an "other" component to capture
> toolchain or miscellaneous requests.  Only the highest level tracker
> bugs are going to be dissociated from specific components, like "docs in
> progress," or trackers of that nature.  There should be few enough of
> those that they can live in "other" without a problem, I would think.
> Since any bug can conceivably become a tracker by having other bugs
> block it, making a separate component for tracker bugs could create
> needless confusion, couldn't it?

No tracker component.  Trackers belong to a specific product and
component.

Some of the trackers are going to be redundant, in that they won't be
needed anymore.

> This reminds me to ask:  How hard is it to add components later?  With
> one component per doc, as more docs are added (here's where I start
> dreaming again), we will need to continually add more components.  Don't
> get me wrong, I like that idea best; I'm just wondering whether this
> presents a potential delay.  I'm not very familiar with how the
> administration of BZ works from an "inside RH" perspective.

This is my first time with this, and I asked Dave about that.
Currently, the process is manual.  We need one, we ask for one.  There
may be some tools in the future, as this is going to get more common.

- Karsten
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
                       Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-dsco-list/attachments/20050711/11117130/attachment.sig>