Publican Documentation Naming

[Toshio Kuratomi]

Tom "spot" Callaway wrote:
> On 04/01/2009 09:31 AM, Paul W. Frields wrote:
> 
>>>> make build WITHOUT="en de fr cz" WITH="es"
>> Those changes would be to the packaging CVS Makefile.common, I take
>> it.  Interesting, I didn't know there was such a request outstanding.
> 
> To be fair, I don't know if there is a formal request outstanding, but I
> know it is something that has been discussed on and off for years.
> 
I know of no formal request.  Hard to say what the koji maintainers will
think about this without that.  My WAG is that they won't like it as:

1) It reduces the reproducability of builds.  koji can store the
WITH/WITHOUT flags but someone getting the SRPM from the build won't
know what those flags were.

2) How are we going to decide whether to keep the SRPMS?  Every time we
update the package and build with only a limited number of languages
we'll be leaving some language packages built from the old SRPM around.
   So we could end up saving a huge number of SRPMS (up to one for every
translation) rather than the current latest or latest + (latest - 1).

>>>> Also, if we're "stuck" on a tool where we are in fear to make changes to
>>>> improve it or fix bugs, how open source is that tool?
>>>>
>>>> I seriously doubt the package committee would endorse an approach that
>>>> throws hundreds of documentation packages (different only in
>>>> translation) at the review system, nor do I think it is likely that they
>>>> would vote to approve guidelines that enables all of these individual
>>>> packages to be reviewed in one ticket. However, that is just my opinion,
>>>> and you're certainly welcome to draft a formal proposal.

I would be for throwing each translation at the review system if we
can't find a better way (and I don't think that WITH/WITHOUT is a better
way).  I would not be for reviewing all of these packages in one ticket.
 I would be for a streamlined process if it can be sanely decided what
that process is.

The problem is that we're dealing with content rather than code here.  A
translation of a book is a book in and of itself (Just browse Amazon for
 Machiavelli's The Prince to see this phenomena with multiple
translations *into a single language*.)  Each book has its own release
schedule, own revisions, etc.

Options:
1) Docs could lay an artificial release schedule on all of the
publications  (ie: new versions of the Security Guide will be released
quarterly.  Authors and translators need to have their work submitted by
 Month/Day in order to be included in the new package)

2) We can have one source package per translation.  I personally don't
see a Guideline issue with this.  But the burden on docs increases
because they need to provide packagers, reviewers (and maintain all of
these packages as they make revisions) in order for this to succeed.

3) We could get the CC repo that's been bandied about up and running and
stick docs content in there (that means that we'd have dependencies
between the two repos, though.)

4) There could be one source package that encompasses the book and its
translations and docs updates these as new revisions come in.  End users
will have to download a new revision every time one of the translations
changes although presto might mitigate some of that.

>> Ian mentioned that subpackages can be passed through to bodhi without
>> implicating all the siblings, which relieves the burden quite a bit.
> 
> Are you sure about this? This would be news to me, but if it is true, it
> would mean that the biggest concern around translations in subpackages
> is minimized.
> 
Unfortunately, it's not true.  Pushing in bodhi associates with a source
rpm rather than built-binary packages.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20090401/5eeabd86/attachment.sig>