= Proposed System Wide Change: Hide the grub menu =
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
Owner(s):
* Hans de Goede <hdegoede at redhat dot com>
On systems with only a single OS installed, the grub menu does not
offer any useful functionality, so we should hide it by default.
== Detailed description ==
On systems with only a single OS installed, the grub menu's only
function is to allow booting older kernels, which is only necessary as
a rescue option in case of a severe kernel bug and as such not
something which is directly useful for normal use.
Fedora already has a lot of work done to not show too technical boot
messages to end users during bootup, e.g. we pass quiet to the kernel
and we've plymouth to show a bootsplash instead of a bunch of
"Starting service-foo: OK" messages.
The grub menu with its kernel versions is another example of showing
too technical info to end-users and on non multi-boot systems it
normally is not necessary, so it is better to hide it.
The implementation of this consists of the following changes:
1. Currently if the menu is hidden the user needs to press ESC to show
it, modify grub to also except F8 as show-menu key, there are 2
reasons for this:
1.1 F8 is (was) the key to bring up the boot/rescue menu in Windows
1.2 On some machines ESC brings up the firmware-setup menu
2. On non multi-boot systems set GRUB_HIDDEN_TIMEOUT=1 and
GRUB_HIDDEN_TIMEOUT_QUIET="true" in /etc/default/grub
== Scope ==
* Proposal owners:
1. Add patches to grub to also make pressing F8 show the menu
2. Make sure this is all properly documented in release-notes, etc.
3. Write patches for anaconda to set GRUB_HIDDEN_TIMEOUT=1 and
GRUB_HIDDEN_TIMEOUT_QUIET="true" in /etc/default/grub on non
multi-boot systems
* Other developers:
The anaconda developers will need to review and merge the
/etc/default/grub related patches
* Release engineering:
https://pagure.io/releng/issue/7539
** List of deliverables: all
* Policies and guidelines:
The policies and guidelines do not need to be updated.
* Trademark approval:
Not needed for this Change.
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Node.js 10.x as default Node.js interpreter =
https://fedoraproject.org/wiki/Changes/Nodejs10
Owner(s):
* Stephen Gallagher <sgallagh at redhat dot com>
A major upgrade to the newest LTS release of Node.js for Fedora 29.
== Detailed description ==
Node.js releases a new LTS version each year and will support it for
around 18 months, which makes it the ideal candidate for use with
Fedora. Node.js 10.x was released recently and is already available as
a module for Fedora 28 and Fedora 29. This Change proposal is to make
10.x the default version shipped with Fedora 29.
== Scope ==
* Proposal owners:
Node.js SIG will need to upgrade the `nodejs` package in Fedora 29 to
10.x (the same package as is available in modules for F28)Node.js SIG
will need to update any `nodejs-*` packages in Fedora 29 if they
require changes to run on Node.js 10.x, or else retire those that no
longer function.
* Other developers:
As this is a major update to a language interpreter, packagers of
Node.js modules will need to test that their software remains
compatible.
* Release engineering:
The upgrade *may* require a side-tag while updating the `nodejs-*`
packages. This is not yet certain.
RelEng ticket: https://pagure.io/releng/issue/7537
** List of deliverables:
Does not ship on default media.
* Policies and guidelines:
No changes expected
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
As of the 29th of May 2018, Fedora 26 has reached its end of life
for updates and support. No further updates, including security
updates, will be available for Fedora 26. Fedora 27 will continue to receive
updates until approximately one month after the release of Fedora 29.
The maintenance schedule of Fedora releases is documented on the
Fedora Project wiki [0]. The Fedora Project wiki also contains
instructions [1] on how to upgrade from a previous release of Fedora
to a version receiving updates.
Regards,
Mohan Boddu.
[0]
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedu…
[1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
Planned Outage - Fedora Production Openshift - 2018-05-31 21:00 UTC
There will be an outage starting at 2018-05-31 21:00UTC,
which will last approximately 3 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2018-05-31 21:00 UTC'
Reason for outage:
We will be re-installing our production openshift cluster. This will
allow us to resize nodes to the recommended sizes for new openshift
releases, upgrade to 3.9 and enable new features we want to try out.
Apps will be reloaded as soon as the cluster is back up.
Affected Services:
bodhi
waiverdb
greenwave
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/6998
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
= Proposed Self Contained Change: java-11-openjdk - next LTS OpenJDK
release and future main JDK in Fedora =
https://fedoraproject.org/wiki/Changes/java-11-openjdk-TechPreview
Owner(s):
* Jiri Vanek <jvanek at redhat dot com>
OpenJDK have LTS release cadence of 2 years. JDK11, next LTS is to be
released September 2018. Next LTS is JDK15, expected in 2020. This
proposal, is proposing new package - java-11-openjdk, based on this
LTS OpenJDK 11, which will be tech preview of next Main JDK for fedora
(30?).
See same process with JDK8, current main JDK, and JDK7 before.
JDK8 tehc preview: https://fedoraproject.org/wiki/Features/Java8TechPreview
JDK8 made main JDK: https://fedoraproject.org/wiki/Changes/Java8
See announcement:
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
See java SIG plans:
https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf
== Detailed description ==
JDK11 is next major, LTS, release of Java platform. It is bringing
many cool improvements - http://openjdk.java.net/projects/jdk/11/ and
is landing to your Fedora. Where it will be maintained for f27 and
newer.
To understand JAva release process, See announcement:
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
and See java SIG plans:
https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf
. So this is package, containing exact LTS version of OpenJDK
You will always be allowed to install Used LTS in fedora build root,
alongside with latest STS via alternatives. Also JDK8 will be with us
for some time
The fate of JDK10 is about to be decided - it can be updated to JDK11
or obsoleted by java-11-openjdk. In all cases, it will be later
updated to JDK12. Also in all cases separate package will be created
for any LTS JDK - next is java-11-openjdk,
All those packages java-1.8.0-oepnjdk, java-openjdk and
java-11-openjdk will be installable in parallel. You can also have
installed several versiosn of java-openjdk installed next to each
other. They are in your /usr/lib/jvm/java-X-openjdk-v-r.a directory.
Where X is major - like 1.8.0, 9, 10, 11 or 12.
== Scope ==
* Proposal owners:
This is isolated change. The maintainers of OpenJDK in Fedora must
build the binaries, and keep them working. To keep jdk8 and jd10
installable in parallel.
* Other developers:
Should start to check theirs packages against JDK11, as it will
replace JDK8 sooner or later. This is still nothing official, and you
can get troubles when trying it with rpmbuild, as your dependencies
may (more likely will) pull JDK8 into build root. But you can try to
compile your sources against JDK10 to see how your upstream get
adapted to modules, and possibly start to upstream patches.
* Release engineering:
https://pagure.io/releng/issue/7527
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Fedora package maintainers,
FESCo approved an updated policy for packages which fail to build from
source during mass rebuilds (FTBFS) [1].
The updated policy is still at https://fedoraproject.org/wiki/Fails_to_build_from_source.
Highlights:
- packages which FTBFS are subject to orphaning if there is no
maintainer acknowledgement within 8 weeks
- packages which FTBFS in two consecutive mass rebuilds will be
retired soon after the second mass rebuild
The implementation of this policy hinges on improving the releng
scripts used to create and manage FTBFS bugs. There is approximately
two months until the next use of those scripts, so I'm hopeful we'll
get them working.
If your package wasn't successfully built for F28, please fix that!
[1] https://pagure.io/fesco/issue/1890
[2] https://pagure.io/fesco/issue/1877#comment-509161
Hi Fellowship of Fedora,
as we have not reach the minimal number of nominees to FESCo required
by FESCo election policy [1], to get ready for voting, FESCo has
decided to prolong the nomination period for one week.
As such, the Nomination period has been re-opened until May 31st @
23:59:59 UTC. Till this deadline you can nominate your self or you can
nominate someone else, who might be, from your perspective, a valuable
member of FESCo. If you nominate someone else, please consult with
that person ahead of time.
Please use the FESCo Nomination page [2] to apply.
[1] https://fedoraproject.org/wiki/FESCo_election_policy
[2] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
Thanks for your support,
Jan
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic