devel-announce October 2013

devel-announce@lists.fedoraproject.org

6 participants
11 discussions

Fedora 20 Beta to slip by one week
by Jaroslav Reznik 31 Oct '13

31 Oct '13

Today at Go/No-Go meeting it was decided to slip Fedora 20 Beta release by one week due to unresolved blocker bugs not being fixed by the time of meeting. Due to constrained schedule, shorter slip was considered but with limited QA resources availability, it was decided to slip for a full week. FESCo will be contacted for further schedule adjustments. Beta release is now planned for Nov-12. More details in meeting minutes [2]. The next Go/No-Go meeting is on Thursday, Nov 07, the same time in #fedora-meeting-2 channel. [1] http://qa.fedoraproject.org/blockerbugs/milestone/20/beta/buglist [2] http://meetbot.fedoraproject.org/fedora-meeting-2/2013-10-31/f20_beta_gono-… [3] https://fedoraproject.org/wiki/Releases/20/Schedule

1 0

Fedora 20 Beta Go/No-Go Meeting #2, Thursday, October 31 @ 17:00 UTC
by Jaroslav Reznik 31 Oct '13

31 Oct '13

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

1 0

Announcing the Cloud Working Group
by Matthew Miller 25 Oct '13

25 Oct '13

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>

1 0

Announcing the Workstation Working Group
by Josh Boyer 25 Oct '13

25 Oct '13

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

1 0

Announcing the Fedora Server Working Group
by Stephen Gallagher 25 Oct '13

25 Oct '13

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

1 0

Fedora 20 Beta to slip by one week
by Jaroslav Reznik 24 Oct '13

24 Oct '13

Today at Go/No-Go meeting it was decided to slip Fedora 20 Beta release by one week due to unresolved blocker bugs, see the blocker tracking app [1]. More details in meeting minutes [2]. As a result, ALL MAJOR MILESTONES, and their dependent tasks, will be pushed out by one week [3]. The new Fedora 20 GA date is now Dec 10. The next Go/No-Go meeting is on Thursday, Oct 31, the same time in #fedora-meeting-2 channel. [1] http://qa.fedoraproject.org/blockerbugs/milestone/20/beta/buglist [2] http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-24/fedora-meeting… [3] https://fedoraproject.org/wiki/Releases/20/Schedule

1 0

Fedora 20 Beta Go/No-Go Meeting, Thursday, October 24 @ 17:00 UTC
by Jaroslav Reznik 21 Oct '13

21 Oct '13

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. Thursday, October 24, 2013 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) "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 Jaroslav

1 0

BEAST to be patched in NSS
by Eric Christensen 16 Oct '13

16 Oct '13

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

1 0

Fedora 20 Beta Change Freeze
by Dennis Gilmore 16 Oct '13

16 Oct '13

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

1 0

F21/F22 System Wide Change: Python 3 as the Default Implementation
by Jaroslav Reznik 09 Oct '13

09 Oct '13

= 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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce October 2013