Two more concrete ideas for what a once-yearly+update schedule would
look like
by Matthew Miller
Trying to make this idea a little more concrete. Here's two suggestions
for how it might work. These are strawman ideas -- please provide
alternates, poke holes, etc. And particularly from a QA and rel-eng
point of view. Both of these are not taking modularity into account in
any way; it's "how we could do this with our current distro-building
process".
Option 1: Big batched update
1. Release F26 according to schedule
https://fedoraproject.org/wiki/Releases/26/Schedule
2. At the beginning of October, stop pushing non-security updates
from updates-testing to updates
3. Bigger updates (desktop environment refreshes, etc.) allowed into
updates-testing at this time.
4. Mid-October, freeze exceptions for getting into updates-testing
even.
5. Test all of that together in Some Handwavy Way for serious
problems and regressions.
6. Once all good, push from updates-testing to updates at end of
October or beginning of November.
Option 2: Branching!
1. Release F26 according to schedule.
2. July/August: branch F26.1 from F26 (not rawhide)
3. Updates to F26 also go into F26.1 (magic happens here?)
4. No Alpha, but do "Beta" freeze and validation as normal for
release.
5. And same for F26.1 final
6. And sometime in October/November, release that (but without big
press push).
7. GNOME Software presents F26.1 as upgrade option
8. F26 continues in parallel through December
9. In January, update added to F26 which activates the F26.1 repo.
10. And also in January updates stop going to F26.
Some of this idea, by the way, is reminiscent of Spot's suggestions at
FUDCon Lawrence in 2013. This is not completely coincidence - I always
liked those ideas!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 years, 8 months
Xulrunner - intent to remove from Fedora 24
by Martin Stransky
Hi,
does anyone use the xulrunner package? (and gecko-devel actually).
Mozilla does not maintain it any more and the XUL as technology is going
to be removed/deprecated. I'd like to remove the package from Fedora 24.
ma.
6 years, 10 months
F25 Self Contained Change: IBus Emoji Typing
by Jaroslav Reznik
= Proposed Self Contained Change: IBus Emoji Typing =
https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing
Change owner(s):
* Takao Fujiwara <tfujiwar [at] redhat [dot] com>
The IBus core will provide the Emoji Unicode typing with the IBus XKB engines.
== Detailed Description ==
IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now we
think the similar implementation for the Emoji typging. With IBus XKB engines,
Emoji typing will be provided with the Emoji annotations [1] following Ctrl-
Shift-e.
== Scope ==
* Proposal owners:
- IBus core provide the dictionary of the Emoji typing.
- IBus XKB engines load the Emoji dictionary.
* Other developers: N/A
* Release engineering: N/A
- List of deliverables: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
[1] http://unicode.org/emoji/charts/index.html#col-annotations
6 years, 11 months
iproute package update policy
by Phil Sutter
Hi,
So far my idea of maintaining Fedora's iproute package was to do full
version updates only in Rawhide and backport patches selectively to
stable versions on behalf of bug reports.
But since stable versions indeed receive full kernel updates (not just
backported patches), there is an understandable amount of frustration
amongst users when the shiny new kernel that comes with e.g. F22
provides features userspace does not support.
Especially since upstream iproute2 does not really have a concept of
stable versions, I'm in a bit of a dilemma here: update to keep in sync
with the kernel or not update to not unnecessarily destabilize the
system?
Any comments/advice are highly appreciated.
Thanks, Phil
7 years, 1 month
whatever happened to yum + btrfs snapshotting?
by Neal Becker
Some time back there was discussion of being able to rollback yum updates via
btrfs snapshotting. As I recall, it turned out that the default btrfs install
was not setup correctly to make this feasible (I had briefly tested it on my
machine). I haven't heard anything since - this seems like a great idea.
--
-- Those who don't understand recursion are doomed to repeat it
7 years, 1 month
Is Kalpa Welivitigoda still active at maintaining packages?
by Iiro Laiho
Hi,
I am asking if anyone knows anything about the whereabouts of Fedora developer Kalpa Welivitigoda? He is the maintainer of unetbootin package. Bug 1229874 would need fixing, but it seems that he is not responding to the bug comments anymore. I tried to ask him about that matter via Facebook as well last Tuesday, but he doesn't seem to respond there either.
– Iiro Laiho
7 years, 2 months
Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel
to -modesetting by default coming to rawhide
by Hans de Goede
Hi,
A while back Debian has switched to using the modesetting Xorg driver
rather then the intel Xorg driver for Intel GPUs.
There are several good reasons for this, rather then repeating them
I'm just going to point to the Debian announcement:
https://tjaalton.wordpress.com/2016/07/23/intel-graphics-gen4-and-newer-n...
This mail is to let all Fedora users know that starting with
Fedora-26 / rawhide as of today, we are making the same change.
Note that the xorg-x11-drv-intel package has already been carrying
a Fedora patch to not bind to the GPU on Skylake or newer, even
before Debian announced this, this just makes the same change for
older Intel GPUs.
For people who are using the now default GNOME3 on Wayland session,
nothing changes, since Xwayland always uses glamor for X
acceleration, just like the modesetting driver.
If you encounter any issues causes by this change, please file
a bug in bugzilla.
Regards,
Hans
7 years, 2 months
F26 Self Contained Change: Anaconda LVM RAID
by Jan Kurik
= Proposed Self Contained Change: Anaconda LVM RAID =
https://fedoraproject.org/wiki/Changes/AnacondaLVMRAID
Change owner(s):
* Vratislav Podzimek (Anaconda/Blivet) <vpodzime AT redhat DOT com>
* Heinz Mauelshagen (LVM) <heinzm AT redhat DOT com>
Use LVM RAID instead of LVM of top of MD RAID in the Anaconda installer.
== Detailed Description ==
In the current situation when a user chooses LVM (or Thin LVM)
partitioning in the Custom Spoke and then sets RAID level for the VG
Anaconda (and Blivet) create an MD RAID device which is used as a PV
for the VG. With this change we are going to use LVM RAID directly
instead. That means that all the LVs in that VG will be RAID LVs with
the specified RAID level. LVM RAID provides same functionality as MD
RAID (it shares the same kernel code) with better flexibility and
additional features expected in future.
== Scope ==
* Proposal owners:
-- Blivet developers: Support creation of LVM RAID in a similar way as
LVM on top of MD RAID. (Creation of RAID LVs is already supported.)
-- Anaconda developers: Use the new way to create LVM RAID instead of
creating LVM on top of MD RAID.
-- LVM developers: LVM RAID already has all features required by this change.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
* Trademark approval:
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
Is there something wrong with the Koji builders?
by Kaleb S. KEITHLEY
I've done two builds for rawhide this morning.
On the first the armv7hl and ppc64le builds failed because the source
tar file could not be unpacked.
On the second the aarch64 build failed because the source tar file could
not be unpacked.
All the other arches built successfully.
--
Kaleb
7 years, 2 months
F26 System Wide Change: GCC7
by Jan Kurik
= System Wide Change: GCC7 =
https://fedoraproject.org/wiki/Changes/GCC7
Change owner(s):
* Jakub Jelínek <jakub AT redhat DOT com>
Switch GCC in Fedora 26 to 7.x.y, rebuild all packages with it, or
optionally rebuild just some packages with it and rebuild all packages
only in Fedora 27.
== Detailed Description ==
GCC 7 is currently in stage3, will move to stage4 on January 19th, in
prerelease state with only regression bugfixes and documentation fixes
allowed. The release will happen probably in the middle of April. We
are working on scratch gcc rpms and will perform a test mass rebuild.
== Scope ==
All packages should be rebuilt with the new gcc once it hits f26, or,
if there is not enough time for that, just all packages built after
the new gcc hits the buildroots.
* Proposal owners:
Build gcc in f26, rebuild packages that have direct dependencies on
exact gcc version (libtool, llvm, gcc-python-plugin, odb).
* Other developers:
First few days/weeks just voluntary rebuilds using the new system gcc,
if things fail, look at http://gcc.gnu.org/gcc-7/porting_to.html and
fix bugs in packages or, if there is a gcc bug or suspected gcc bug,
analyze and report.
* Release engineering:
Organize a mass rebuild, either in f26 or in f27
* Policies and guidelines:
No policies need to be changed
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months