To packagers who are listed below,
New entry will be introduced into the devel-task-list:
"Build F12 collection packages for all language translators' review and
Start: 2009-09-11 End: 2009-09-14
This entry requires you to rebuild your package with latest translation
by 2009-09-14, so that a release to be made straight after exclusively
for translators' review (note, this is different from the entry of
Software: Rebuild all translated packages). This is for high standard of
translation quality, and has been accepted on 2009-09-04 by FESCo. The
detail why accepted can be found at . The detail what to be happened
at L10N team side can be found at .
For communicating and tracking purpose a bug will be created soon
against each package, as well everyone of you will be pinged for reminder.
Please notice that amazingly F12 has been translated into 52 language
with more than 40% completion so far, and the percentage as well the
number of languages are aggressively growing.
Your understanding and action are highly appreciated.
Thank you so much for your support to Localization team.
** The list of packages **
ABRT >> master
anaconda >> master
authconfig >> tip
chkconfig >> master
comps >> HEAD
desktop-backgrounds >> HEAD
desktop-effects >> master
firstboot >> master
hwbrowser >> tip
im-chooser >> trunk
initscripts >> master
kexec-tools >> HEAD
libuser >> tip
multimedia-menus >> master
policycoreutils >> HEAD
pykickstart >> master
python-meh >> master
readahead >> master
redhat-menus >> HEAD
rhpxl >> master
setroubleshoot >> tip-plugins
setroubleshoot >> tip-framework
setuptool >> master
smolt >> master
smolt >> master-smoon
sos >> trunk
switchdesk >> HEAD
system-config-audit >> tip
system-config-bind >> tip
system-config-boot >> master
system-config-cluster >> HEAD
system-config-date >> master
system-config-datev >> docs
system-config-date >> master-timezones
system-config-display >> master
system-config-firewall >> master
system-config-httpd >> tip
system-config-kdump >> master
system-config-keyboard >> trunk
system-config-kickstart >> master
system-config-language >> trunk
system-config-lvm >> master
system-config-netboot >> trunk
system-config-network >> master
system-config-nfs >> docs
system-config-nfs >> master
system-config-printer >> 1.1.x
system-config-rootpassword >> trunk
system-config-samba >> docs
system-config-samba >> master
system-config-services >> docs
system-config-services >> master
system-config-users >> docs
system-config-users >> master
system-switch-java >> tip
system-switch-mail >> HEAD
usermode >> tip
Noriko Mizumoto (irc:noriko) from FLP
Over the past few months, Fedora Infrastructure has been discussing
having a consistent set of licenses for applications and scripts we
create for Fedora. The goals of doing this were to
* Be able to share code among the various programs that we write.
* Not have our libraries force a specific license on the apps that we write.
* Not have conflicting licenses between our apps and our libraries
* Have a clear understanding of the steps we must take whenever we want
to move code from an application under one license to a library under a
* Protect the code we write from being taken proprietary (note, this is
not the same for every author. Mirrormanager, for instance, is under the
* Be able to stay compliant with licenses within our production,
staging, and publictest environments
At last week's meeting we made a decision about which licenses would
best fit our needs. The results are recorded here:
The basics are:
* license code that is meant to be used as a library as LGPLv2+.
* license code that's meant to be used as an application as GPLv2+.
* If we want to write something and use another license we should
discuss it to figure out how it's going to impact us and whether there's
a better way to achieve our goals first.
Most of our apps are currently under GPLv2(only) so we're going to be
working to change the licensing on those apps over time to reflect GPLv2
or later. If you find something that we've written that's not under
GPLv2+ (or LGPLv2+) that you want to use, please let us know so we can
either get to work on making the license match the guidelines or let you
know why it's not being changed.
The one other thing for Infrastructure developers and System Admins to
note in the Policy is the section on handling AGPLv3 applications.
During the discussions about whether to use AGPLv3+ for our web
applications we found and delimited many issues that need to be
addressed when deploying AGPLv3+ licensed code. The aGPL portion of the
policy is our first attempt at keeping us compliant with any code that
is under this license. Highlights are:
* Apps deployed to production under AGPL must be deployed from RPMs.
Any hotfixes to those apps must have the patch in a ticket in trac on
http://fedorahosted.org/fedora-infrastructure with the keyword HOTFIX.
* Any AGPL app deployed in infrastructure must have links in the footer
to the fedora-infrastructure SRPM repo and the trac query that pulls up
our hotfixes so that people can find the exact source that we're running
at any given time.
* Staging must follow the same rules regarding SRPM and hotfixes. Once
again, failing to link to the exact source for what we have running
would put us out of compliance.
* No AGPL apps can be hosted on publictest boxes at this time as
publictest boxes are intended for development and the high rate of
change in development is not conducive for constantly updating RPMS or
patches in trac. If there's demand for publictest hosting of AGPL apps
we'll need to design some method of restricting who can access the
applications running there to satisfy the legal requirements.