[publican-list] Publican SRPMs in Fedora

[Jeffrey Fearn]

Eric Christensen wrote:
>> Totally agree. Using separate SRPMs is important to keep a
>> maintainable/scalable localization work-flow.
>>
>> Cheers
>>
> 
> That makes sense if you don't have a single maintainer of the SRPMS.
> For the Fedora guides and articles (like the Release Notes) there is a
> single maintainer of the SRPM.

This is the scenario we tested pre-RHEL 5 and having a gate keeper for 
all languages proved to be one of the biggest problems. It simply does 
not scale, the gate keeper gets swamped, updates get delayed, and the 
system falls down.

We were dealing with less than half the languages Fedora supports and we 
had a dedicated team of full timers on hand, so this is not a trivial 
problem in the Fedora space.

>  So as translations are completed for the
> Release Notes the maintainer adds them to the SPRM and does the update
> in the packaging system.

This failed miserably when we tried this, how are you going to make it 
work without changing the approach?

I'll concede that the release notes have a special place somewhere 
between help text and stand alone docs, but because of this it is a poor 
example of why you'd add this to a system dedicated to packaging stand 
alone documentation.

> This has the benefit of including a single package in the release that
> Yelp will automagically select the proper language for the user.

Yelp is less than optimal for many reasons, such as: you just lost all 
your branding, you are tied to a single desktop, you just increased the 
payload by 50 times, you are ignoring section 508 compliance, etc.

>  This
> is quite important as so the end user won't have to do anything but
> select the document they are wanting to read.  No fuss.

You can do that without yelp, without coupling to a particular desktop, 
without losing the section 508 work we have done, without over riding 
their chosen HTML viewer, etc.

I'm still waiting for an approach that isn't "we will do it the same way 
you did it when it failed, but it will just work now (TM)."

Cheers, Jeff.

-- 
Jeff Fearn <jfearn at redhat.com>
Software Engineer
Engineering Operations
Red Hat, Inc
Freedom ... courage ... Commitment ... ACCOUNTABILITY