Flock Schedule posted, F21 Schedule review, Fedora.next brand design and test planning, and Ruby SCL package review.
Fedora is a big project, and it’s hard to follow it all. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for May 27th, 2014:
Flock is Fedora’s annual contributor conference, held this year in Prague on August 6th through 9th. The schedule is now up on sched.org. The organizers reserve the right to make tweaks as needed, but this should mostly be the final schedule.
Last year’s conference was amazing, and I think this year will be even better. There are a lot of great talks, hackfests, and workshops planned over a busy four days, along with a vibrant “hallway track” and fun social events (yet to be detailed). In general, we will get a lot of real planning and solid work done, all built on top of Fedora’s “Friendship” foundation. If you’re a Fedora contributor and not sure if you should come, you should. Register now at the Flock site.
Thanks to everyone who proposed talks and to everyone who voted on those proposals. And thanks to Flock organizers Josh Boyer, Tom Callaway, and Ruth Suehle, who used those votes as the primary source for the difficult jigsaw puzzle that is putting together the schedule. Thanks also to Miro Hrončok and Jiri Eischmann for working out venue logistics.
Fedora 21 Schedule Reminder
Speaking of schedules… as we get to the end of May, it seems like a good time to give a reminder of the Fedora 21 schedule. The summer is going to go fast! So, a refresher:
- June 6: Mass Rebuild. This means that Release Engineering will cause every package in the distribution to be rebuilt from source, with the newest compilers and toolchains. Package maintainers need to be prepared to fix any problems that are exposed. (Packages that don’t build and aren’t updated will eventually be dropped from the distribution.)
- July 8: Change Freeze and Branch from Rawhide. The first of these means that any official change proposals for F21 need to be a) substantially complete and in a testable state and b) enabled by default (if that’s the plan for that change). We have a rather large change set planned for this release, and many of those changes involve big new Fedora.next ideas. The second means that Fedora 21 will become a distinct repository from Rawhide, our rolling development tree. That means that any changes packagers make that are intended for F21 will go through the normal package updates process — and it means that testers can decide if they want to divert their systems to the upcoming release, or to keep on Rawhide to follow the bleeding edge of what will eventually become the release after next.
- July 22: Alpha Change Deadline and Software String Freeze. The change deadline basically means that except for accepted fixes, everything that’s going to land in the alpha release should be there already. And the string freeze means that packages for which Fedora is the upstream should stop making user-visible changes so that translators have time to work.
- August 5: Alpha Release. The Fedora 21 Dress Rehearsal — we’ll get real picture of what the upcoming release will look like (and where there are still rough edges).
- August 26: Beta Change Deadline, Changes 100% Complete, and Software Translation Deadline. Similar to the deadlines for Alpha, but more so. Proposed changes which are off-track at this point may need to be scaled back or delayed until the next release.
- September 9: Beta Release. Everything will be shaping up, and we’ll be more concerned with polish than development. If you have an idea for a big change at this point, that’s awesome — the Rawhide development tree continues to be open for business so progress can continue.
- September 30: Final Change Deadline. All the last changes should be in.
- October 14: Fedora 21 Final Release! Fedora Cloud, Fedora Server, Fedora Workstation, and all the spins and the rest will go into the world.
All of these dates are officially expressed as “no earlier than”. As always the schedule may… flex… a little bit, but generally we aim to actually hit these targets. That gives us just 20 weeks from now — mark your calendars!
Fedora.next Preliminary Branding
The Fedora Design Team is working on a plan for presentation of the three different Fedora products we’ll be releasing this fall as part of the Fedora.next initiative. Each of these will need their own logo, but they also need a coherent look that ties them together as part of the overall Fedora Project. Fedora Contributor Máirín Duffy kicks off the process with some starting-point designs, which you can see at read about at Fedora.NEXT Brand Concept #1.
What do you think? What ideas do you have?
Fedora 21 Test Planning
Those three products will also need testing; that’s one of the reasons the schedule is longer than the typical six months. Fedora Quality Assurance “Community Monkey” Adam Williamson wrote a draft test plan for Fedora 21 in general, outlining different areas of work and responsibilities. If you’re interested in helping (or just curious), read Adam’s message about this draft and join the conversation on the Fedora Test Mailing List.
Help Wanted (Soon) for Software Collection Package Reviews
Software Collections is a way to package software into RPMs which sit in
/opt, outside of the main part of the distribution. The main use case of Software Collections (SCLs, for short) is to have a stack of software which moves at a different speed from the distro proper — in RHEL or CentOS, that usually means faster, but in Fedora, it could be a way to provide consistent runtime environments across multiple releases.
Specifically, we’re planning to have a Ruby 1.9.3 with Rails 3.2.8 SCL in Fedora 21 as a first experiment, led by Fedora contributor Marcela Mašláňová. Since F21 will have Ruby 2.1.x with Rails 4.1, this will let users with code that isn’t ready for the new version update to newer Fedora — but port their own code on their own schedule
The Fedora Packaging Committee has been working on draft guidelines, and the remaining big hurdle is that the 60-some new packages will need to go through the standard review process. The plan is to make this as painless as possible, by organizing an online activity day to crank through them. If you’ve done some package reviews (and ideally if you know Ruby), and are interested in helping, watch the Environments and Stacks mailing list for more soon.