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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
