2009/3/31 Eric Christensen <eric@xxxxxxxxxxxxxxxxxxx>: > 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 > > -- > fedora-docs-list mailing list > fedora-docs-list@xxxxxxxxxx > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list > You'd be bumping the release number every iteration you added something and thus a new 'version' Toshio: Comments would be welcome here -- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
