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.
I'm adding these three items to the agenda for this week's Docs meeting[3].
[1] http://fedoraproject.org/wiki/PackagingDrafts/DocumentationNaming [2] http://fedoraproject.org/wiki/PackagingDrafts/EmbeddedDesktopFiles [3] http://fedoraproject.org/wiki/Docs_Project_Steering_Committee_meetings
Thanks, Eric
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.
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
2009/3/31 Eric Christensen eric@christensenplace.us:
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@redhat.com 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
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
On Tue, Mar 31, 2009 at 04:57:53PM -0400, Eric Christensen wrote:
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.
I think we're talking apples and oranges here. Let me see if I can clarify. This might be pedantic for people who already do packaging (and if there are errors, of course you should blame me!).
In most cases in Fedora, subpackages make good sense. If you are packaging "libfoo," a library that provides a capability for "foo," you generally have one libfoo SRPM that generates several other packages -- libfoo and libfoo-devel, for example. (There might also be an automatically generated libfoo-debuginfo, but let's leave that aside for now.)
When you change something in the libfoo package to fix a bug, bumping the release from libfoo-1.0-1 to libfoo-1.0-2, it makes very good sense to push new libfoo and libfoo-devel packages at one time. The possibility that things *might* change from libfoo-1.0-1 to libfoo-1.0-2 make it a good practice to simply always act as if they *have* changed when issuing new packages. When you issue a new libfoo-1.0-2, you'll always push out a new libfoo-devel-1.0-2 as well.
Now, that works fine for documentation too, in *that* case -- in other words, if you make some changes to the basic Security Guide, you would of course want to push out the newest Guide in all languages. But here's where the subpackage use breaks down: You never see packagers issuing a new libfoo-devel package without libfoo changing. And that can *definitely* happen in documentation.
For example, you could add a new, previously unused translation to your Guide. Using subpackaging, in order to issue it, you'd have to rebuild the entire set of languages, and when you do, our build system -- as far as I know -- won't let you just push the one new language subpackage out. It would require *all* the language subpackages to be reissued, even if they hadn't changed at all.
Here's another twist that might make subpackages even more unpalatable. It implies that there will be a *resistance* to pushing out translation fixes quickly. There will be a tendency to wait before reissuing packages. Subpackages may lower the workload for a small Docs team -- you could only issue a quarterly update, or on some other regular but liveable basis -- but arguably at the cost of friction with the translation teams.
I also think subpackaging makes life harder for the Docs team member responsible for a Guide. The job of coordinating translations for a specific mass release in one big package is quite a bit more wearying than pushing out updated translations onesie-twosie style as they come. (Package rebuilds and pushes are generally very easy with our tools.)
Just some food for thought. And of course, it would have been great to have this stuff considered way back when in the requirements phase for the tool, but hindsight, and all that. Hope this information helps the Docs team.
I'm cc'ing Spot because I don't know if he's on this list.
On 03/31/2009 06:07 PM, Paul W. Frields wrote:
Now, that works fine for documentation too, in *that* case -- in other words, if you make some changes to the basic Security Guide, you would of course want to push out the newest Guide in all languages. But here's where the subpackage use breaks down: You never see packagers issuing a new libfoo-devel package without libfoo changing. And that can *definitely* happen in documentation.
Sure. We see this happening all the time, for bug fixes.
For example, you could add a new, previously unused translation to your Guide. Using subpackaging, in order to issue it, you'd have to rebuild the entire set of languages, and when you do, our build system -- as far as I know -- won't let you just push the one new language subpackage out. It would require *all* the language subpackages to be reissued, even if they hadn't changed at all.
You could, but how often does this _ACTUALLY_ happen?
Here's another twist that might make subpackages even more unpalatable. It implies that there will be a *resistance* to pushing out translation fixes quickly. There will be a tendency to wait before reissuing packages. Subpackages may lower the workload for a small Docs team -- you could only issue a quarterly update, or on some other regular but liveable basis -- but arguably at the cost of friction with the translation teams.
Honestly, if this is a significant enough problem to need solving, we should solve it with other mechanisms than overloading CVS with hundreds of otherwise identical packages.
We could find a way for koji to build specific subpackages for translated %doc packages. The spec files would need a set of conditionals, and we'd need to standardize on lang variables, then build a mechanism to pass the conditionals through to the builder.
I would prefer that mechanism, for example. I suspect that Jesse would too (but I'm CC'ing him in case I'm wrong).
~spot
On Tue, Mar 31, 2009 at 06:14:56PM -0400, Tom spot Callaway wrote:
On 03/31/2009 06:07 PM, Paul W. Frields wrote:
Now, that works fine for documentation too, in *that* case -- in other words, if you make some changes to the basic Security Guide, you would of course want to push out the newest Guide in all languages. But here's where the subpackage use breaks down: You never see packagers issuing a new libfoo-devel package without libfoo changing. And that can *definitely* happen in documentation.
Sure. We see this happening all the time, for bug fixes.
Really? People issue a libfoo-devel-1.0-2 package without a concomitant libfoo-1.0-2 package?
For example, you could add a new, previously unused translation to your Guide. Using subpackaging, in order to issue it, you'd have to rebuild the entire set of languages, and when you do, our build system -- as far as I know -- won't let you just push the one new language subpackage out. It would require *all* the language subpackages to be reissued, even if they hadn't changed at all.
You could, but how often does this _ACTUALLY_ happen?
I can tell you this happens VERY often, IME in Fedora Docs.
Here's another twist that might make subpackages even more unpalatable. It implies that there will be a *resistance* to pushing out translation fixes quickly. There will be a tendency to wait before reissuing packages. Subpackages may lower the workload for a small Docs team -- you could only issue a quarterly update, or on some other regular but liveable basis -- but arguably at the cost of friction with the translation teams.
Honestly, if this is a significant enough problem to need solving, we should solve it with other mechanisms than overloading CVS with hundreds of otherwise identical packages.
Wait, are these identical? AIUI the SRPMs contain different language content. The en-US SRPM has en-US DocBook XML content, the de-DE SRPM has de-DE DocBook XML content, etc.
We could find a way for koji to build specific subpackages for translated %doc packages. The spec files would need a set of conditionals, and we'd need to standardize on lang variables, then build a mechanism to pass the conditionals through to the builder.
I would prefer that mechanism, for example. I suspect that Jesse would too (but I'm CC'ing him in case I'm wrong).
In which case we're back to being stuck when we try to push those spec changes back upstream to Publican, right?
On 03/31/2009 09:12 PM, Paul W. Frields wrote:
Really? People issue a libfoo-devel-1.0-2 package without a concomitant libfoo-1.0-2 package?
Concomitant? No. But with changes that only affect libfoo-devel? Yes.
Wait, are these identical? AIUI the SRPMs contain different language content. The en-US SRPM has en-US DocBook XML content, the de-DE SRPM has de-DE DocBook XML content, etc.
They are identical, with the exception of the "output language". More to the point, the hundreds of spec files would be identical.
We could find a way for koji to build specific subpackages for translated %doc packages. The spec files would need a set of conditionals, and we'd need to standardize on lang variables, then build a mechanism to pass the conditionals through to the builder.
I would prefer that mechanism, for example. I suspect that Jesse would too (but I'm CC'ing him in case I'm wrong).
In which case we're back to being stuck when we try to push those spec changes back upstream to Publican, right?
I wouldn't say "stuck". The changes should be reasonably minimal. I gave this some thought last night, and it might be something that could be implemented along with a semi-longstanding feature request with koji: the ability to pass specific --with or --without options through to the build task. Each lang could be a --with or --without as needed. With some Makefile.common love, it could be as easy as:
make build WITHOUT="en de fr cz" WITH="es"
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.
~spot
On Wed, Apr 01, 2009 at 08:39:47AM -0400, Tom spot Callaway wrote:
On 03/31/2009 09:12 PM, Paul W. Frields wrote:
In which case we're back to being stuck when we try to push those spec changes back upstream to Publican, right?
I wouldn't say "stuck". The changes should be reasonably minimal. I gave this some thought last night, and it might be something that could be implemented along with a semi-longstanding feature request with koji: the ability to pass specific --with or --without options through to the build task. Each lang could be a --with or --without as needed. With some Makefile.common love, it could be as easy as:
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.
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.
Ian mentioned that subpackages can be passed through to bodhi without implicating all the siblings, which relieves the burden quite a bit.
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.
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.
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.
~spot
On Wed, Apr 01, 2009 at 09:56:35AM -0400, 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.
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.
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.
Q.v.: http://www.redhat.com/archives/fedora-docs-list/2009-March/msg00234.html
Ian, can you confirm this is correct?
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
On Wed, 2009-04-01 at 09:31 -0400, Paul W. Frields wrote:
Ian mentioned that subpackages can be passed through to bodhi without implicating all the siblings, which relieves the burden quite a bit.
I'm about 100% sure that this is not possible. That's just not how koji works.
On Wed, 2009-04-01 at 08:39 -0400, Tom "spot" Callaway wrote:
I gave this some thought last night, and it might be something that could be implemented along with a semi-longstanding feature request with koji: the ability to pass specific --with or --without options through to the build task. Each lang could be a --with or --without as needed. With some Makefile.common love, it could be as easy as:
make build WITHOUT="en de fr cz" WITH="es"
This isn't going to work if you're trying to just produce new subpackages, because the way koji works is at an srpm level. that is, if you issue a new build of a package, only the output of that build is published. Output from previous builds will be removed, even if the new buidl only has a few subpackages and the old build has many more. We don't carry forward any part of previous builds.
On Tue, Mar 31, 2009 at 04:54:04PM -0400, Paul W. Frields wrote:
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.
However if the packages do not require each other (makes sense) and they are subpackages, one can only choose certain subpackages to submit as an update to Bodhi, IIRC.
On Tue, Mar 31, 2009 at 05:42:44PM -0500, Ian Weller wrote:
On Tue, Mar 31, 2009 at 04:54:04PM -0400, Paul W. Frields wrote:
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.
However if the packages do not require each other (makes sense) and they are subpackages, one can only choose certain subpackages to submit as an update to Bodhi, IIRC.
Ah, this is something I got wrong. The build process would still be tremendously long-winded for a small nugget of actual package we care about, but I suppose that is, in fact, why we use computers to do it and not pencil and paper (or monkeys with typewriters). ;-)
There are no such package Requires: AFAIK. Worth factoring into the equation, thanks Ian.
-
David Nalley -
Eric Christensen -
Ian Weller -
Jesse Keating -
Paul W. Frields -
Tom Callaway -
Toshio Kuratomi