Documenting Changes
by Pete Travis
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
https://fedoraproject.org/wiki/Category:Documentation_beats?rd=Docs/Beats ,
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
- immanetize(a)fedoraproject.org
10 years, 1 month
F21 schedule: what would you do with more time?
by Matthew Miller
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>
10 years, 1 month
Fedora 20 Bugzilla Rawhide rebase
by Jaroslav Reznik
Greetings,
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.
Jaroslav
10 years, 1 month
Fedora 20 Mass Branching
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All,
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.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlIT7AQACgkQkSxm47BaWffWEgCgkw9eldBN1H0hBSna3lWQ0FzG
63AAn2/qomutLvZQe/jsxk8PcsBtHDq2
=mUyD
-----END PGP SIGNATURE-----
10 years, 1 month
Fedora 20 Changes Freeze today & tracking bugs
by Jaroslav Reznik
Hi!
All Changes Tracking bugs should be reported now [1] 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:
https://fedoraproject.org/wiki/Releases/20/ChangeSet
* 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 [2]. Fedora 20 is really pretty
tight, as we wanted to avoid major holidays, so help us with
tracking status of this release!
Thanks
Jaroslav
[1] https://bugzilla.redhat.com/buglist.cgi?component=Changes%20Tracking&prod...
[2] https://fedoraproject.org/wiki/Releases/20/Schedule
10 years, 1 month
[ACTION REQUIRED] Retiring long-term FTBFS packages for Fedora 20
by Till Maas
The following packages did not build for two releases and will be
retired around 2013-08-26 unless someone rebuilds them or announces to
actively working on fixing them.
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one.
Package (co)maintainers
===========================================================================
curry gemi, oliver
eclipse-phpeclipse mbooth, swagiaal
libgarmin fab
libvpd emunson, hegdevasant, fkocina, lnykryn, rrakus,
jskala
lsvpd emunson, hegdevasant, fkocina, lnykryn, wolfy,
rrakus, jskala
mod_mono chkr
nautilus-sendto-trac mbooth
open-cobol s4504kr
petitboot dwmw2, tbreeds, jwboyer
python-pylons kylev, cicku
simulavr ndim
smart athimm, scop
synce-connector awjb
tango-icon-theme cwickert
tango-icon-theme-extras cwickert
The following packages require above mentioned FTBS packages:
Depending on: python-pylons
python-repoze-what-pylons (maintained by: spot, lmacken)
python-repoze-what-pylons requires python-pylons = 1.0-4.fc17
Depending on: smart
PackageKit (maintained by: rhughes, rdieter, stefw, jcm, rnorwood, lmacken, rhughes, timlau, tuxbrewr)
PackageKit-smart requires smart = 1.3.1-68.fc17
fedora-package-config-smart (maintained by: athimm, scop)
fedora-package-config-smart requires smart = 1.3.1-68.fc17
Depending on: synce-connector
synce-gnome (maintained by: awjb)
synce-gnome requires odccm = 0.15.2-5.fc17
synce-kpm (maintained by: awjb)
synce-kpm requires odccm = 0.15.2-5.fc17
Depending on: tango-icon-theme
gnome-theme-curvylooks (maintained by: pgordon)
gnome-theme-curvylooks requires tango-icon-theme = 0.8.90-6.fc17
Affected (co)maintainers
athimm: smart
awjb: synce-connector
chkr: mod_mono
cicku: python-pylons
cwickert: tango-icon-theme-extras, tango-icon-theme
dwmw2: petitboot
emunson: lsvpd, libvpd
fab: libgarmin
fkocina: lsvpd, libvpd
gemi: curry
hegdevasant: lsvpd, libvpd
jcm: smart
jskala: lsvpd, libvpd
jwboyer: petitboot
kylev: python-pylons
lmacken: python-pylons, smart
lnykryn: lsvpd, libvpd
mbooth: nautilus-sendto-trac, eclipse-phpeclipse
ndim: simulavr
oliver: curry
pgordon: tango-icon-theme
rdieter: smart
rhughes: smart
rnorwood: smart
rrakus: lsvpd, libvpd
s4504kr: open-cobol
scop: smart
spot: python-pylons
stefw: smart
swagiaal: eclipse-phpeclipse
tbreeds: petitboot
timlau: smart
tuxbrewr: smart
wolfy: lsvpd
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find-unblocked-orph...
10 years, 1 month
[ACTION REQUIRED] Retiring packages for Fedora 20 v2
by Till Maas
The following packages are orphaned or did not build for two
releases and will be retired when Fedora (F20) is branched, unless someone
adopts them. If you know for sure that the package should be retired, please do
so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
According to https://fedoraproject.org/wiki/Schedule branching will
occur not earlier than 2013-08-20. The packages will be retired shortly before.
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one.
Package (co)maintainers
===========================================================================
PyOpenGL orphan
bluecove orphan
bunny orphan
cal3d orphan
cpptasks orphan
dayplanner orphan, rakesh
drehatlas-warender-bibliothek-fonts orphan, fonts-sig
examiner orphan
firmware-extract orphan, mebrown, praveenp
firstboot orphan, msivak, mgracik, clumens, bcl
gkrellm-timestamp orphan
gnaural orphan
justmoon orphan, mmahut
lybniz orphan
manaplus orphan
mars-sim orphan, mmahut
openstack-tempo orphan, vaneldik, josecastroleon,
markmc
osgal orphan
python-durus orphan
python3-cherrypy orphan
txt2rss orphan
zanata-python-client orphan, seanf, jamesni, dchen,
petersen
The following packages require above mentioned orphaned/FTBS packages:
Depending on: PyOpenGL
cura (maintained by: churchyard)
cura requires PyOpenGL = 3.0.1-7.fc20
impressive (maintained by: mjg)
impressive requires PyOpenGL = 3.0.1-7.fc20
pipviewer (maintained by: fab)
pipviewer requires PyOpenGL = 3.0.1-7.fc20
pycam (maintained by: zultron)
pycam requires PyOpenGL = 3.0.1-7.fc20
pygtkglext (maintained by: jwrdegoede, turki)
pygtkglext requires PyOpenGL = 3.0.1-7.fc20
qmforge (maintained by: jussilehtola)
qmforge requires PyOpenGL = 3.0.1-7.fc20
Depending on: cpptasks
gluegen (maintained by: limb, teseu)
gluegen requires cpptasks = 1.0b5-9.fc19
gluegen2 (maintained by: davidcl, davidcl)
gluegen2 requires cpptasks = 1.0b5-9.fc19
gluegen2-devel requires cpptasks = 1.0b5-9.fc19
jogl (maintained by: limb, davidcl)
jogl requires cpptasks = 1.0b5-9.fc19
jogl2 (maintained by: davidcl, java-sig)
jogl2 requires gluegen2 = 2.0-0.9.rc12.fc20
jogl2 requires gluegen2-devel = 2.0-0.9.rc12.fc20
scilab (maintained by: davidcl)
scilab requires jogl2 = 2.0-0.9.rc11.fc20
scilab requires jogl2 = 2.0-0.9.rc11.fc20
scirenderer (maintained by: davidcl, java-sig)
scirenderer requires jogl2 = 2.0-0.9.rc11.fc20
scirenderer requires jogl2 = 2.0-0.9.rc11.fc20
Depending on: manaplus
tmw (maintained by: mgieseki)
tmw requires manaplus = 1.3.3.17-2.fc20
tmw-music (maintained by: mgieseki)
tmw-music requires tmw = 20130201-2.fc20
Affected (co)maintainers
bcl: firstboot
churchyard: PyOpenGL
clumens: firstboot
davidcl: cpptasks
dchen: zanata-python-client
fab: PyOpenGL
fonts-sig: drehatlas-warender-bibliothek-fonts
jamesni: zanata-python-client
java-sig: cpptasks
josecastroleon: openstack-tempo
jussilehtola: PyOpenGL
jwrdegoede: PyOpenGL
limb: cpptasks
markmc: openstack-tempo
mebrown: firmware-extract
mgieseki: manaplus
mgracik: firstboot
mjg: PyOpenGL
mmahut: justmoon, mars-sim
msivak: firstboot
petersen: zanata-python-client
praveenp: firmware-extract
rakesh: dayplanner
seanf: zanata-python-client
teseu: cpptasks
turki: PyOpenGL
vaneldik: openstack-tempo
zultron: PyOpenGL
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find-unblocked-orph...
10 years, 1 month
F20 System Wide Change: Migrate to Bluez 5
by Jaroslav Reznik
= Proposed System Wide Change: Migrate to Bluez 5 =
https://fedoraproject.org/wiki/Changes/Bluez5
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
ported.
* 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
snapshot.
* 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
maintainers.
* Release engineering:
No release engineering coordination required.
* Policies and guidelines:
No changes needed in the packaging guidelines.
10 years, 1 month
