Publican Documentation Naming

[Toshio Kuratomi]

David Nalley wrote:
>> On Tue, 2009-03-31 at 16:54 -0400, Paul W. Frields wrote:
>>>>
>>>> Also discussed was the multiple SRPMs that are generated by having
>>>> multiple languages for each document.  To simplify the process of
>>>> reviewing these it was suggested that we use subpackaging.  Each SRPM
>>>> for each language would be wrapped into a single package.
>>> Allow me to play Devil's Advocate for a moment -- one of the reasons
>>> for splitting out SRPMs per language, AIUI, is that it allows fixed
>>> translations to be issued quickly without having to rebuild the entire
>>> gamut of all languages for a document.  In other words, if someone
>>> fixes the Security Guide's German (de) translation, you can simply
>>> issue a new release of that package, and only people with the Security
>>> Guide installed in German will get the update.
>>>
>>> As far as I know, you can't tell our build systems to only
>>> release one subpackage, and hold back all the others.  So if you want
>>> to issue an update, you would be forced to issue all languages at
>>> once, and you push an update on everyone, even people whose content is
>>> not changing at all.
>>>
>>> Just my limited understanding, there may be good arguments on both
>>> sides of course.

> 
> You'd be bumping the release number every iteration you added
> something and thus a new 'version'
> 
> Toshio: Comments would be welcome here
> 

Yeah, I think Paul is pointing to a very real problem here which wasn't
apparent in the meeting earlier.  Let me make a little chart of the
drawbacks of each style:

One source package, one binary package per language:
* Each time one language is updated, the source package is rebuilt into
many binary rpms.  Even if there are changes to only one language.  This
means that new packages will be available for the user to download and
install on next update.
  - This is mitigated a little if presto support is working for F11 as
presto should keep users from actually downloading things that haven't
changed.  it still means that the update system (PackageKit) will detect
changes and want them to update, though.
  - Even with Presto, it makes it hard to determine when changes
actually occur to a specific translation of a document if there's a
bunch of releases where the changes only happened to another
translation.  Maybe it's not as problematic with documentation as with
code, though....

One source package per language per Fedora release:
* This quickly creates a lot of packages which will all need packagers
and reviewers.
* The packages will need to be rebuilt whenever that translation changes
which means packagers will have to track changes to the many documents
involved.

If docs manpower scales to the task, I'd say tackling the problems with
one-source-package-per-language would better fit how I visualize the
documentation.  If you think this is the case then we can carry the new
issue of updating all translations of the package when just a single
translation has changed over to fedora-packaging list.

If you think there will be a struggle to meet these needs, maybe we need
to think of a different solution.

-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://lists.fedoraproject.org/pipermail/docs/attachments/20090331/5eefb4d6/attachment.bin