The Fedora Documentation Project, as part of the Changes process, is
using bugzilla tickets to track the documentation of Changes. Those of
you tracking tickets for System Wide Changes probably noticed that I
recently cloned your bugs for this, and I'll move on to the and here's
what's going on:
First, you should know that you aren't expected to work on these
tickets. Docs writers will take them, and the information already in
the Change page is usually enough to get the process rolling. It helps
if you can answer any questions that might pop up, of course.
Each Change ticket is blocking two docs tickets. One is to track
representation of the Change in the official Release Notes that are
shipped with the media and published to docs.fedoraproject.org . The
other is filed against the "docs-requests" component, which is
traditionally used to request new documentation or for task tracking.
This second bug is for us to do a general assessment of the existing
documentation - I'm expecting to do some tasteful grepping - and open
bugs for guides that need to be updated to reflect the Change.
While I've got your attention, I want to mention that if you have
anything interesting that might fit in the Release Notes - or any other
docs - you can jot a note in the wiki page at
mail the list at docs(a)lists.fedoraproject.org , set the
fedora_requires_release_note flag in a bug, drop in to #fedora-docs.
Again, don't worry about presentation and such; it can be difficult to
know what needs to be written about in the distribution and a point in
the right direction really helps.
-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
Based on discussion at Flock, on the devel mailing list, and in the FESCo
meeting, we are looking for feedback on the idea of a longer release cycle
for Fedora 21 -- not (right now at least) the bigger question of the 6-month
cycle overall, but just, right now, slowing down for a release to get some
things in order.
Specifically, both Release Engineering and QA have clear needs (and even
plans for) greater automatiion, but are also incredibly busy simply doing
the things they need to do _now_ to get the release out the door.
So, FESCo would like to see some specifics, like "If we had one week with
nothing else to worry about, we could have automated generation and upload
of cloud images" (to pick an example I personally care about). Or "with six
months of overall delay, we could have continuous integration testing of a
key subset of rawhide". Or "we could spend a couple of weeks and automate
the new package and review workflow".
What Infrastructure projects would be helped by this? Web and design team,
would slowing down the release focus allow time to work on, oh, say, getting
the Wiki beautiful (or does it not matter)? What else?
As we look at Fedora.next ideas and possibly decide to start implementation
in the F21 timeframe, we will likely find _new_ things that take specific
work. Let's not worry about that right now. What things we do _now_ could be
improved with the investment of some effort?
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
This e-mail is intended to inform you about the upcoming Bugzilla changes
happening the week after August 20, 2013 (Rawhide bug rebase) and what you need
to do, if anything.
We will be automatically changing the version for most rawhide bugs to Fedora 20.
This will result in regular bugs reported against rawhide during the Fedora 20
development cycle being changed to version ‘20' instead of their
current assignment, ‘rawhide’. This is to align with the branching of
Fedora 20 from rawhide and to more accurately tell where in the lineage of
releases the bug was last reported.
Note that this procedure does not apply to bugs that are open for the ‘Package Review’
component or bugs that have the ''FutureFeature'' or ''Tracking'' keywords set.
They will stay open as rawhide bugs indefinitely.
If you do not want your bugs changed to version ‘20‘, add the FutureFeature keyword.
If you need help changing a large amount of bugs manually, we’d be glad to help.
The process was re-approved by FESCo https://fedorahosted.org/fesco/ticket/1096.
-----BEGIN PGP SIGNED MESSAGE-----
Fedora 20 has been branched, please be sure to do a git pull --rebase to
pick up the new branch, as an additional reminder rawhide/f21 has had
inheritance cut off from previous releases, so this means that
anything you do for f20 you also have to do in the master branch and do
a build there. This is the same as we did for fedora 19.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
-----END PGP SIGNATURE-----
All Changes Tracking bugs should be reported now  as a
replacement for tracking changes/features in the wiki page and
using usually meaningless percentage status. Please, use this
tracking bug for bugs blocking your Change (if you already have
a tracking bug, ignore this one and please change component to
Changes Tracking one).
Full list of accepted Changes by FESCo is on:
* What should I do with my Change now?
According to the policy, the Change has to be substantially complete
and in a testable state; enabled by default -- if so specified by the
Change. If the above applies for you Change, please set bug status
to MODIFIED state. Otherwise if your Change is at risk, please,
write a new comment to the bug with the current status and let me
know. We'll try to deal with this situation.
Current schedule is available at . Fedora 20 is really pretty
tight, as we wanted to avoid major holidays, so help us with
tracking status of this release!
there will be a soname version bump in evolution-data-server update
3.9.90 the next week, namely for libedata-book and libedata-cal
libraries. Affected might be evolution-mapi and evolution-ews, which are
updated together with it anyway. If there will be more, and I have
commit access to them, then I rebuild them as well.
= Proposed System Wide Change: Migrate to Bluez 5 =
Note: post deadline exception to coordinate BlueZ 5 effort as upstreams were
not clear to move to it in the time of submission deadline.
Change owner(s): Bastien Nocera, Kalev Lember, and the desktop SIG
BlueZ is the Linux Bluetooth stack for managing wireless Bluetooth devices. In
Fedora 20, we are going to switch from BlueZ version 4 to version 5.
== Detailed description ==
The BlueZ project recently released BlueZ version 5. Compared to BlueZ version
4, the new release brings new features and improvements, however it is also
accompanied by a significant API change. The BlueZ versions 4 and 5 are not
parallel installable, and we need coordination between various parts of Fedora
to switch over at the same time.
This is coming late after the Change Proposals Submission Deadline. As this
affects various critical parts of the distribution (KDE, GNOME, NetworkManager,
pulseaudio), we wanted to be sure it is feasible to switch everything over at
the same time, and were considering postponing it to Fedora 21. However,
upstreams have made good progress with porting over to BlueZ 5 and we feel it
would be beneficial for Fedora to switch over during the Fedora 20 timeframe.
== Scope ==
BlueZ 5 uses a D-Bus API that's not compatible with BlueZ 4 and as such,
management applications and a number of libraries and daemons need to be
* Proposal owners:
This is a change affecting many parts of the distribution. The proposal owners,
supported by the rest of the Desktop SIG, are going to take care of updating
the BlueZ package to version 5 and porting over gnome-bluetooth,
NetworkManager, and PulseAudio packages.
* KDE SIG:
The bluetooth stack for KDE is BlueDevil. It has a git branch with BlueZ 5
support and the Fedora KDE SIG will handle updating the package to a git
* Desktop SIG:
For GNOME 3.10, Gustavo Padovan and Bastien Nocera have been porting gnome-
bluetooth, NetworkManager and PulseAudio to BlueZ 5, and the Fedora Desktop
SIG will ensure these get updated to the BlueZ 5 versions in Fedora.
* NetworkManager team:
... will ensure the relevant NetworkManager changes land in Fedora 20.
* MATE team:
mate-bluetooth has not received much upstream attention recently and is likely
to not get ported to BlueZ 5 in time for F20. However, the Fedora MATE
maintainers are looking into switching back to using gnome-bluetooth, and
creating a panel applet for MATE that uses gnome-bluetooth underneath. An
initial prototype is available at https://github.com/NiceandGently/bluetooth-panel-applet
* Other developers:
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other
applications relying on Bluez4 will need to be ported by their respective
* Release engineering:
No release engineering coordination required.
* Policies and guidelines:
No changes needed in the packaging guidelines.