Fedora 21 Retrospective

Introduction

This page is intended to gather feedback from the Fedora community on things that worked well and things that could have been better during the Fedora 21 release cycle. The feedback will be used as a basis for identifying areas for improvement for Fedora 22 and could weigh into the Fedora 22 Schedule. Any thoughts, big or small, are valuable. If someone already provided feedback similar to what you'd like to add, don't worry ... add your thoughts regardless.

See Also

Several different Fedora teams have their own retrospective process. See:

• Fedora 21 QA Retrospective
• F21 marketing retrospective
• (others?)

Providing feedback

• Kevin Fenzi - I liked that we made a retrospective wiki page.

Adding feedback is fairly straight forward. If you already have a Fedora account ...

1. Login to the wiki
2. Select [Edit] for the appropriate section below.
3. Add your feedback using the format:

   * ~~~ - I like ____ about the new ____ process

4. When done, Submit your changes

Feedback

Things that went well

• Sudhir Khanger - Every single release whether alpha, beta, RC, etc.they all worked flawlessly and were very stable. Kudos to developers, maintainers and the hard work done by the QA team.
• M. Edward (Ed) Borasky - I was impressed by how quickly the bugs I found in building my remix were fixed.
• Paul Frields - Acclaim for the release has been almost unanimous in the public and press. This isn't to say F21 is bug-free, but it's clear the devotion of the entire community to quality (shepherded by QA) has resulted in a great release.

Could have been better

• M. Edward (Ed) Borasky - The documentation for Fedora Cloud, especially Project Atomic was "typical of a young project". I think it could be better.
• Paul Frields - Despite having a year-long release cycle to accommodate splitting up the release into different editions, it seems like a lot of stress fell on numerous teams late in the cycle.
• Paul Frields - I heard complaints from developers they were not consulted or involved in blocker bug activities/decisions as expected, which resulted in frustration.

Wishlist

• Sudhir Khanger - I get the reasons why OpenJDK 7 had to be dropped from Fedora 21 but dropping something because it goes EOL before the EOL of the release is not the best way to accomplish the goals.
  • Omajid (talk) Any suggestions on a better way to accomplish the goal? Would it be better to drop OpenJDK7 from a release when OpenJDK7 went EOL? Wouldn't that mean that we either leave users with an unsupported version of the JDK or force upgrade them to OpenJDK8?
• M. Edward (Ed) Borasky - If this is 'wishes for F22', my fondest wish is for some kind of architectural / software mechanism for seamlessly integrating the various language packaging systems on a Fedora core. Just about every Python developer I know has a mix of "native" Linux packages and packages living in a virtualenv installed with 'pip'. In my case, I'm installing R from Fedora (or Ubuntu or openSUSE) but installing the packages from CRAN or even from source repositories via 'devtools'. And don't get me started on Node.js / npm. ;-) This is error-prone and hard to reproduce / maintain / document.
• User:aarem -I sincerely hope that Fedora can consider a rolling-release model in addition to the existing Fedoras. This would be a nice addition to the existing mix of Fedora and RHEL/Centos. Call it Cap or Fez or Topi or whatever, but some of us like the leading-edge aspect of Fedora software and we would not like to waste our time on upgrading. This also ensures worry-free (certainly worry-free) maintenance by users who have had someone more experienced to install Fedora for them and who do not really want to go back to them every 6-12 months for an upgrade. Upgrading ever-so-often is actually a barrier for some people wanting to get into Fedora/CentOS OSS OS. It would therefore be nice to have an additional distribution with a leading-edge-software-based rolling-release model.