Fedora 20 Beta Go/No-Go Meeting #2, Thursday, October 31 @ 17:00 UTC
by Jaroslav Reznik
Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 20 Beta.
This is the second attempt to release Fedora 20 Beta. Currently, we're
waiting for possible RC1 compose.
Thursday, October 31, 2013 17:00 UTC (1 PM EDT, 10 AM PDT, 18:00 CET)
"Before each public release Development, QA and Release Engineering meet
to determine if the release criteria are met for a particular release.
This meeting is called the Go/No-Go Meeting."
"Verifying that the Release criteria are met is the responsibility of
the QA Team."
For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting
In the meantime, keep an eye on the Fedora 20 Beta Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/20/beta/buglist
PS: sorry for late reminder but I'm sick...
Jaroslav
9 years, 11 months
Announcing the Cloud Working Group
by Matthew Miller
I sent a message about this yesterday to the Cloud SIG mailing list, but
neglected to send to the wider community. Also, I just listed people without
introductions, and although I think all of these names should be familiar to
many of us, that seems like a nice thing. So:
I'm pleased to annouce that the following people have agreed to be voting
members of the initial working group:
* James Antill -- FPC member, yum maintainer. Will help with the tools
we'll need to build a brave new containerized world.
* Robyn Bergeron -- Former Fedora Cloud SIG wrangler, now the FPL. Driver
of Fedora for those who value mean time to recover over mean time
between failure. Talks regularly with smart people in awesome
innovative open software communities outside of our traditional
comfort zone.
* Joe Brockmeier -- Fedora Marketing contributor, and also member of
the Apache CloudStack PMC. Will help with market research,
marketing, communications, and as much as we can trick him into
taking on.
* Haïkel Guémar -- Longtime Fedora contributor (packager, ambassador,
writer), and works on cloud computing for $DAYJOB, and so will provide
a voice for real-world users.
* Sam Kottler -- Works with Puppet and is a member of Bundler and
RubyGems core teams. Has opinions, not afraid to use them. Does
not sleep.
* Sandro Mathys -- Another longtime contributor, active in OpenStack
and RDO, also works on cloud computing for actual money; will
provide real-world experience and contribute to QA.
* Matthew Miller -- Me. FESCo coordinator, cheerleading, that sort of
thing.
* Frankie Onuonga -- Member of the Fedora Infrastructure team,
interested in release engineering. Works for a public cloud
startup hopefully going live next week with Fedora images.
* Mattias Runge -- Fedora contributor and OpenStack developer. Has
presented a somewhat different idea of where we should go with
this than what I suggested, which is good in case I'm entirely
wrong.
As Josh noted in the Workstation WG announcement, I also want to
strongly stress that while the above people are the initial voting
members, we're looking for participation from anyone interested in
helping Fedora succeed as a cloud operating system.
We will be using using the existing Cloud SIG mailing list
(cloud(a)lists.fedoraproject.org) and #fedora-cloud IRC channel for group
communication.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
9 years, 11 months
Announcing the Workstation Working Group
by Josh Boyer
The initial Fedora Workstation Working Group has been formed and
ratified by FESCo as of yesterday. FESCo has appointed me as the
coordinator and I am pleased to announce the following people as
members of the initial voting group:
Owen Taylor: He will be able to discuss upstream Gnome plans and adds
a lot of knowledge on desktop interactions.
Kalev Lember: He will be able to provide community focused input and
feedback into what is needed for a successful workstation product.
Christoph Wickert: Long time Fedora member, will bring experience from
both XFCE and LXDE desktop environments. Can help with
inter-operability aspects between DEs, etc.
Lukáš Tinkl: Long time core KDE developer. Will be able to provide
feedback and insight into that DE as well as what that class of user
looks for in a workstation.
Jens Petersen: Will add i8n and developer experience to the team,
helping the workstation product in those areas.
Ryan Lerch: Fedora Design representative. Will help with UI and design
experience.
Matthias Clasen: GNOME desktop team lead. Lots of experience with
Fedora and GNOME in a variety of aspects.
Christian Schaller: Desktop manager and Fedora packager. Brings a good
knowledge of workstation products.
Josh Boyer: Coordinator.
While the above people are the initial voting members, I want to
strongly stress that we are looking for participation from anyone
wishing to produce a high quality Workstation product. This is
especially true if you are a member of another group that will be
impacted, such as QA, rel-eng, etc.
Logistics
We are still working out details on our meeting times and IRC
channels. For the time being, we will be using the
desktop(a)lists.fedoraproject.org for our mailing list. Once we get
further details worked out, we'll announce them here and on that list.
Thanks!
josh
9 years, 11 months
Announcing the Fedora Server Working Group
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
tl;dr The Server Working Group has been formed and will be meeting on
Wednesday. See the == Logistical Information == section below for details.
== General Announcement ==
As most of you are aware, the Fedora Project is embarking upon a new
venture. Traditionally, the Fedora Project has been a "bag of bits"
collection of packages that attempted to serve everyone's needs
simulataneously. As time has passed, we've discovered that when you
try to please everyone at once, you usually fail to please anyone at all.
Starting at Flock, a new proposal was born: Instead of One Fedora
Project to Rule Them All, why don't we try building three Fedora
Operating Systems from the packages in the Fedora Project. These three
operating systems (dubbed Fedora Server, Fedora Workstation and Fedora
Cloud, initially) were discussed at length, then ultimately proposed
to the Fedora Project Advisory Board, who gave the go-ahead to start
implementation.
We spent about a month eliciting calls for volunteers to serve on five
"Working Groups". There is one group built around the planning and
execution of each of these new Fedora Products and then the "Base
Design" group, which will be responsible for ensuring that the
products share a common core and an "Environments and Stacks" group
that will investigate how best to deploy software from the larger
Fedora Project ecosystem atop these new Fedora Products.
Part of the planning process for these new working groups was for us
to set up an initial voting membership who has two initial
responsibilities[1]:
1) Establish a governance charter - determine how to run the Working
Group and elect voting members. This charter is due on November 15,
2013 and must be ratified by FESCo.
2) Produce a Product Requirements Document (PRD) - This is a statement
of target audience and the role of the project (what problems it
will solve and what niche it will fill). This is a high-level view
of the Product. This document is due in January, 2014 and must be
ratified by the Fedora Advisory Board.
To talk a little bit about the voting membership. It should be noted
that these are NOT the only members of the Server WG that can
participate. We strongly encourage the participation of all of the
larger Server SIG in this effort. Ultimately, the voting membership
will be the ones to make (and vote on) final decisions, particularly
in the case of controversy or disagreement. This should never be done
without careful consideration of all the facts.
The initial voting membership was selected by the FESCo coordinator
(me, Stephen Gallagher).
* Jim Perrin: He will bring to the table an idea of what the CentOS
project would want to see in CentOS 8 for its constituency (which is
notably different from Red Hat's consumers, despite sharing a common
code ancestry)
* David Strauss: He maintains a large existing deployment of Fedora
servers in production and will be able to help us identify its
strengths and weaknesses when used in such a manner.
* Truong Anh. Tuan: Representing the Fedora Ambassadors, he will be
aiding us in producing information that will be useful when talking
about this new product in public.
* Máirín Duffy: As the representative from the Fedora Design Team, she
will be invaluable in all conversations planning for the user
experience and product announcements.
* Kevin Fenzi: Representing Fedora Infrastructure, he will hopefully
keep us grounded in what we can or cannot accomplish in a particular
period of time (as well as having a wealth of knowledge around
real-world deployment scenarios). He is also a member of FESCo,
though not acting as coordinator.
* Miloslav Trmač: Red Hat security engineer who no doubt work
tirelessly to ensure that we ship a product that is tightly
controlled and properly maintained, as well as representing other
low-level security decisions. He is also a member of FESCo, though
not acting as coordinator.
* Simo Sorce: Red Hat engineer representing the identity and policy
management space. His experience with both FreeIPA and Active
Directory will be invaluable as we work out how to coordinate Fedora
Server in heterogenous environments.
* Jóhann B. Guðmundsson: Representing the Fedora QA team, I expect
Jóhann to focus primarily on working to make sure that we do not
make life any more difficult for testers than we strictly must.
== Logistical Information ==
This logistical information is a proposal. We may decide to change
some or all of it as a result of the first meeting of the voting
membership.
This meeting will take place in #fedora-meeting-1 on Wednesday,
November 30 at 17:00 UTC (13:00 EDT, 19:00 CZ). This is immediately
prior to the FESCo meeting at 18:00 UTC, so we will have a strict
one-hour limit on this meeting.
Mailing List: server(a)lists.fedoraproject.org
IRC Channel: #fedora-server on Freenode
[1]
https://fedoraproject.org/wiki/Fedora.next/boardproposal#Product_Working_...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJqX8gACgkQeiVVYja6o6MGfwCfZbtEQaE1sia1VzUqgBhnmPRZ
fUkAnRDpZhX5n6CxIRDNsOjhOZL9fWfz
=JsL9
-----END PGP SIGNATURE-----
9 years, 11 months
BEAST to be patched in NSS
by Eric Christensen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
FESCo met today to address the NSS BEAST patch that left all software using NSS vulnerable to the BEAST[0] vulnerability. The decision was made to implement the patch that fixes this vulnerablity in F19 and F20. There are some programs that may have difficulties with this fix. While the fix will go in as soon as possible the change in F19 will not be applied until some testing has been completed.
Information on this fix is in Bugzilla[1]. If your package depends on NSS you should definitely test this patch before it goes live in order to determine if it breaks functionality (information on the BZ ticket on how to disable the fix if needed).
[0] https://en.wikipedia.org/wiki/BEAST_%28computer_security%29#BEAST_attack
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=665814
- -- Eric
- --------------------------------------------------
Eric "Sparks" Christensen
Fedora Project
sparks(a)fedoraproject.org - sparks(a)redhat.com
097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGcBAEBCgAGBQJSXvf/AAoJEB/kgVGp2CYvN9cL/RQ0iNRgn//6qgggi7aP2VBN
8AeYhxMCLrYMLCHoK5L1NFa85XjkPzyVStEZK5mUh/2YGHMSI5sA0cCOFQlZfB5T
j4LzuKobc5QdcyAntROsMmBP00yJlRnzfCnyl7CPKMN4GAV582R1I8hkvMsCtZat
KvwPFenrkVTEORTf/UG86Ztu92SjWEcbEmmAzp715aui66OuvyROqtS4sxsdGKfL
cklIvsYTEA11+Adju4rdJGGOGZ6AuczM8VNqw4c4rOWjBbNbQl+a2sgdOSqLnaDC
vuO6MIBaXabuWfpkmWwQmIIWCwslZmnMlA2pNvdjkZ4+6fsIXPGyDI65V2CoJ54i
UxBLGBluiIazwAXTmVk+3FhhECyGZ2KzNj0T49tbtYtIrFquW9K68U9Zo67Zaeh2
AXCz5ILVHJcSxYQqaYO2am0maMN4WKY0DF3VeXWRgSMNM033e0tS87HPttmI0RDo
JMW3yxNSaB8yp3YcG77kDwCAnu8cZmrPYAk843Zi3A==
=YObr
-----END PGP SIGNATURE-----
9 years, 11 months
Fedora 20 Beta Change Freeze
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
as the Fedora 20 schedule[1] states the Beta change freeze is upon
us. As of now all Beta freeze only accepted exceptions[2] will be
allowed in.
we are at the beta stage of release, so the Beta_to_Pre_Release[3]
stage of the updates policy applies.
Regards
Dennis
[1] http://fedorapeople.org/groups/schedule/f-20/f-20-devel-tasks.html
[2] http://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[3] http://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJSXi+QAAoJEH7ltONmPFDRBPMQAKS+GiGKPRHisr0SGzXU7j9n
OkMuYe5RNnXcvGWTUJxS6JMRzOltmkipVIMdjV1GQzKUEIQnDSBQe6oZmnhDgCQj
hZTWG5PK/RT0CJc2lMMFDkmDDDM3W7BqLeH23hH7pc8rxG1nJROcyx4Nx8qLi9MX
P/n9n5A92Ej1iKavEIBvDAFvuk2zqG2k6ZHYbXiqBY3E4N45UibZM6EDA8JceOYS
Ga51yDSwzlS7UNXaSA04A9k3gnrjPqwG9qCah6TvKZCpjFt/iGfkv7UhVWpJRvZk
samtuk72gHeIDrxMRxe+V3GMP958NYZSkticYw/2LdRPKS2ncIvjoRlWesxsdAn6
23yvlIgKVyWSp9ArR8tvdiCdxStQAKvGG30uagStkKimZmUP32pJHfw2CvyUPkXi
+dZPlCyG+Mg63PQAtQQmlFo0hEIrEWRD86iKn0GTsYVT9Uob9qhKBaLg9IddNH8Z
EpNInx1P0mFBjnznRMgs5IHjrENCNikVh6K8rv3sPPg4TgniVCpsN5jYG9SUxFVB
7A1HMuGyBHUvust8Xi8hGAtOwSVJUbG3WCrO1UZebirqptRZVscy9M5X8a3rjkBp
Tdopg8lr9QCxN6/REeIS7bd8saW9lSH3aAzxckDsnNwYpHgSdVqRCSshOttGdsGl
7d3ib/ZMmAAnNX5xdKX1
=ExKR
-----END PGP SIGNATURE-----
9 years, 11 months
F21/F22 System Wide Change: Python 3 as the Default Implementation
by Jaroslav Reznik
= Proposed System Wide Change: Python 3 as the Default Implementation =
https://fedoraproject.org/wiki/Changes/Python_3_as_Default
Note: Change requested by FESCo in advance for targeted Fedora.
Change owner(s): Slavek Kabrda <bkabrda(a)redhat.com>, Matej Stuchlik
<mstuchli(a)redhat.com>
Up until now, Fedora has used Python 2 as the default Python implementation.
This change proposes switching to Python 3. The details of the term
"switching" are explained thoroughly in the Scope section.
== Detailed description ==
Python 3 is the next generation of Python programming language. It is
currently mature and stable, since it has been under active development for
five years - version 3.0 was released in December 2008, current latest stable
version is 3.3.2 released in May 2013. The main reason to switch to Python 3
as the default implementation is that Python 2 is in maintenance mode, thus
only bugfixes and security fixes are accepted upstream. Further reasons are
mentioned in the Benefit to Fedora section. For this Change to be carried out
successfully, it is necessary that the key packages in the Fedora software
stack be ported to Python 3. These are parts of the minimal buildroot, the
default package manager, programs present on the LiveCD etc. More information
on the packages involved can be found in Dependencies. While porting of some
packages is rather trivial, other packages need significant amount of work to
get rid of the Python 2 dependence.
== Scope ==
The main goal is switching to Python 3 as a default, in which state:
* DNF is the default package manager instead of Yum, which only works with
Python 2
* Python 3 is the only Python implementation in the minimal buildroot
* Python 3 is the only Python implementation on the LiveCD
* Anaconda and all of its dependencies run on Python 3
* cloud-init and all of its dependencies run on Python 3
(see Dependencies for the list of packages that need to be ported)
This will also require revisiting Python guidelines (broader discussion with
community and FPC approval - TBD). The result of the discussion will reflect in
this Change in further instructions for Fedora packagers.
There are basically two types of packages that need to undergo the conversion:
* Python extension modules and libraries that provide Python bindings -
assuming that there is upstream support, these can receive python3- subpackage
anytime without any damage to Fedora; we can then just utilize this subpackage
when switching to Python 3 (instead of using current python- subpackage).
* Packages that build with some sort of "embedded Python support", like gdb,
or Rhythmbox with its plugins. In these cases, it makes no sense to do a
python3- subpackage, since the whole package would need to be duplicated (e.g.
python3-gdb). These packages should be tested with Python 3 locally without
any modifications to how they're currently built in Fedora. When we get a Koji
side tag, these packages will switch and build against Python 3 in the side
tag.
==== Work in Fedora 21 Timeframe ====
* Proposal owners:
** Discussing changes in Python packaging guidelines with Fedora community and
FPC
** Helping upstreams with porting to Python 3
** Introducing python3- packages where appropriate, testing packages that only
build with Python once (e.g. gdb, Rhythmbox)
* Other developers:
** Hopefully the same as proposal owners.
* Release engineering:
** Nothing in F21 timeframe
* Policies and guidelines:
** As mentioned above, this will require a discussion with community and FPC
and preparation of changes to Python packaging guidelines. The changes related
to the actual switch should however be merged in F22 timeframe and only if the
switch is successful.
==== Work in Fedora 22 Timeframe ====
* Proposal owners:
** Continue the work from F21 timeframe
** Request Koji side tag and encourage packagers to rebuilt their packages
with Python 3 there
** If the switch to Python 3 is achieved in the side tag:
*** Modify comps accordingly
*** Apply the changes to Python packaging guidelines
*** Ask relengs to merge the side tag into F22
** Else:
*** Postpone the Change for another release
*** Do not merge side tag into F22
*** Do not apply changes to Python packaging guidelines
* Other developers:
** Introduce python3- subpackages where appropriate, build against Python 3 in
the side tag where appropriate
* Release engineering:
** Create the Koji side tag
** Merge the side tag back in F22 if the switch is achieved
* Policies and guidelines:
** Apply the changes to Python guidelines if the switch is achieved
9 years, 11 months