On Sat, 2007-01-13 at 19:42 +0200, Ahmed Kamal wrote:
> not sure I understand your question, but they way things should go is,
> the client downloads the drpm, client side code combines client side
> files from older rpm + the drpm into a new rpm. Then that new rpm is
> installed. The required bandwidth should drop to 20%, the numbers need
> some testing ofcourse, but I can imagine such savings.
SuSE did a lot of work on distributing the files as less than a whole
rpm. Their original tool works as you say, with an "rpm patch file"
that combines with an rpm on the client's system which is then
installed. The newer tool that they were pushing a couple years ago was
also able to upgrade files on the filesystem rather than going through
the intermediate step of creating an rpm. I consider this method to be
less desirable from a security standpoint than the first.
Some members from the L10N project have identified some issues that need to be
solved to make sure the translations of Fedora are of high quality. Some of them
are infrastructure-related and at today's (-admin) meeting it was suggested to
transfer the discussion here.
I'm sure the folks at Red Hat are doing their best to keep the quality of the
translations high. But the truth is that Fedora's image in the context of
translations is not good; we do hear that a lot, from current and wanna-be
members. We can and should work to improve it. Semi-translated applications are
U-G-L-Y and shout "low QA" in our ears.
Some possible ideas have been listed on the following page:
Please feel free to chip in and help us out correct whatever doesn't seem
reasonable, break tasks into smaller tasks etc.
The bigger picture of some of these problems are:
* L10N of "local" applications (those listed on ) is poor; releases and
package updates contain untranslated strings in many languages. This is
unacceptable for a fully-localized desktop.
* The barrier to contribute to the l10n (be it GUI or Docs) is higher than it
should be (compared to other projects).
* QA of the translations is difficult with the current tools.
Some more concrete ideas to discuss that might concern the InfrProj and the
RelEng team are:
* Integrate better the handling of translation during a "local" package's
lifecycle. Have a flag raised for a package update that introduces new strings
so that translators can translate the new strings before the
repackaging/updating. Include in the schedule for each release a "string freeze
date" and a week later a "translation freeze date" and have all our packages
rebuilt after the latter and before the actual release.
* Move po files on their own cvsroot on cvs.fedoraproject.org to reduce
complexity and maintenance and to increase security (with a new group).
* Move the i18n status pages to Fedora servers (Plone/Turbogears?). Include a
direct link to the pofiles from there so that new members can have something to
work on before getting cvs access.
* In the future, use Plone to automate the QA between team members (ie
coordinators can review translations etc).
* Start working with the complex and tricky path to upstream translations that
no distribution has tackled yet in a successful way. Bring our translators
closer to the upstream projects.
Hope some of the above make sense. :)
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
dwmw2 asked me if I could do my full rawhide rebuilds on PPC as well
as x86_64 and i386. I don't have ppc hardware, and he doesn't have
ppc hardware with enough disk space or a local rawhide mirror. :-)
As it's just some scripts that call mock, could I run those on the ppc
Extras builders in PHX? They use --uniqueext so they can't conflict
with a normal Plague build job. Would need some disk space for the
results directory (~20GB), and be able to export the results via a web
I'd still do the i386 and x86_64 builds in my lab here as I have been.
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
Here's the schedule, please add anything you'd like to work on if
you're going to be there. Those that know what time they'd like to
work on their specific projects should include it on this page so
others know when to show up if they want to help.
Does anyone know the status of Brew? I seem to remember someone
mentioning that the scheme would be availble already.
Why is the archives of this list not public? If sensitive details are
being discussed in this list, the list membership itself should be
moderated which is not the case at present. If anyone can join the list,
I dont see any harm in letting search engines and other services index
Just FYI, I build a Fedora Core 6 + Updates + Extras "respin" and the
total DVD iso is currently 6Gb (I used pungi to build it, but I
haven't used the resulting DVD for installation yet).
I think with the impending merging of core & extras in F7, this means
people either have to use dual-layer DVDs or there need to be two DVDs
for installation purposes. (or someone needs to 'cut-down' the number
of packages in F7 to get in to fit on 1 DVD).
I also ended with about 10 CD isos, but I'm not going to use them.
I was wondering with the upcoming F7 Test1 Release on 30 January 2007
are there any things for the infrastructure that need to be done yet?
On a side node is there a clear overview of the infrastructure
deliverables in relation with the major milestones of F7 (on
I just looked at the LDAP schema and noticed that there's no numeric
userid/groupid field. We're going to need to carry over the userid and
groupid from the database as those numerics are used in other databases
that refer to records in the account system and on our servers as Unix
We've only partially discussed this. wwoods has requested a Fedora QA project.
He's going to fill out some more detailed goals and description but I
wanted to hear if there are any objections to this. I'm strongly in
favor of setting it up and letting them go at it.