On Tue, 2009-03-31 at 16:54 -0400, Paul W. Frields wrote: > On Tue, Mar 31, 2009 at 02:20:32PM -0400, Eric Christensen wrote: > > Earlier today the Fedora Packaging Committee (FPC) looked at two > > "obstacles" to Publican-generated documentation. The first was the > > naming convention[1] and the second was how Publican handles > > the .desktop in the SPEC file[2]. Both passed the FPC. > > > > The FPC did say that we (the Docs Project) need to create a review > > process to ask "is this documentation really version specific? is there > > value in having multiple releases in the same dist at once?". This is > > an important test that we need to develop and handle in-house. This is > > NOT a solution to allow all Publican documents but it is a solution for > > allowing release-specific documents in Fedora. > > > > 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. Paul, I posed a similar question... I'm pasting the conversation: Sparks_Too> spot: I foresee a problem coming down the road. Each language is packaged independently. So that's going to mean a lot of packages hitting the review process within a short amount of time. <ke4qqq> yeah I was about to bring that up as well. <spot> Sparks_Too: each language is packaged independently? <spot> seriously? that's just broken. <Sparks_Too> spot: Yes <ke4qqq> another tool issue * tatica has quit (Read error: 110 (Connection timed out)) <tibbs> Oh, please no. <spot> yeah, i'm not going to let that slide. <Sparks_Too> spot: In RH the reasoning is so there aren't 200MB docs... <ke4qqq> I suspect it's a plot to dramatically increase fedora package count :) <Sparks_Too> being downloaded for just one language. <spot> learn about subpackages. <Sparks_Too> So you would be able to install a language versus a document. <Sparks_Too> If that makes sense. <abadger1999> subpackage ++ <ke4qqq> right, single srpm, 35 rpms <Sparks_Too> ke4qqq: This is a RH thing and not a Fedora thing. <spot> subpackages should be fine <spot> 35 base packages would not be <Sparks_Too> spot: Okay, not familiar but would be. <Sparks_Too> s/would/will <spot> Sparks_Too: basically, think of how the openssl package generates openssl and openssl-devel <spot> it is just one package for review (openssl) <spot> HowToFooAndBar could generate HTFAB-en and HTFAB-de <Sparks_Too> spot: Okay... so would we need ALL the languages in the package before it is approved? <tibbs> No. You can just add a language once the package is in. <spot> Sparks_Too: nope. you can add subpackages as they are done. <spot> FPC, we're almost out of time <Sparks_Too> spot: Okay. That works for me. Our meeting is tomorrow so I'll bring it up then. I don't have a problem with any of this, just need to learn more. So when he said that not all the translations have to be in the package it sounded to me as if they weren't language specific and we wouldn't run into that problem. Eric
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
