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
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
