Fedora 22 Alpha Freeze
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
Today's an important day on the Fedora 22 schedule[1], with several
significant cut-offs. First of all today is the Bodhi activation point
[2]. That means that from now all Fedora 22 packages must be submitted
to updates-testing and pass the relevant requirements[3] before they
will be marked as 'stable' and moved to the fedora repository.
Today is also the Alpha freeze[4]. This means that only packages which
fix accepted blocker or freeze exception bugs[5][6] will be marked as
'stable' and included in the Alpha composes. Other builds will remain
in updates-testing until the Alpha release is approved, at which point
the Alpha freeze is lifted and packages can move to 'stable' as usual
until the Beta freeze.
Today is also the Software String freeze[7], which means that strings
marked for translation in Fedora-translated projects should not now
be changed for Fedora 22.
Finally, today is the 'completion deadline' Change Checkpoint[8],
meaning that Fedora 22 Changes must now be 'feature complete or close
enough to completion that a majority of its functionality can be
tested'.
Regards
Dennis
[1] https://fedoraproject.org/wiki/Releases/22/Schedule
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
[8] https://fedoraproject.org/wiki/Changes/Policy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJU7MHvAAoJEH7ltONmPFDRcIgQAI0i4FRbZFWtd2+LdoSS7vhJ
e+18nhiBEjh3G+75+FajwMLYL9ptXhMXcdvk78y55dfp2K5cfEDRr8WkCn6QnzT7
T4tynbPMdN7jmOpb9zNPhqoTLzejzkVsSFW50NVId8l4NSh77wcQTvU/ZKU9mN7O
WfpI4xp4lKeZsvooNYplAeVwKsoypY3pc+LgIT+U7PGRM7l74LidMkNTNGLdWd2/
Lks0qwXQSYh/iQ5XQJ2hW2IF+JmWUOxLMXEE23TVQD2AlBvncAJB4ZB3L8p4S+FB
GP/ulYZSRofEzAOKHoUHCfbrLdc8y5/taac1SzGAtd48j1sqMnIWTtLu3c0rTqGY
Sry/zmB6cugiEDrryFoNf/F/QmOAKc9m6PJ7HvHAZUIj5l6N9THa7nwGSg0dFvNv
BpxeFmpo4EFb/Xw17E1uNXIGTaGRrTCse1p7yR3L6FJLSxOMSNIdFN5+DnILHdaP
twm0HW1HpjYczq+Y1lwdDJoG3JYolEukz195xqOwzViikDNmxBWikSJ4wpgILiuK
pCsmXa/I+ePbYmYTZJc/MEwEtIGTZwgwWzRiNhmZlBY3F+NeNBUgCOSMuUpLF0QI
T9hXu3I9vfF1TljJg4H8NoBaTftkuCD2C1C9jH7l34b+82+E7o6RaMMIJ1WEkPHd
JlelrtX35qPpaBhDgDAD
=02J1
-----END PGP SIGNATURE-----
8 years, 9 months
Fedora 22 Bugzilla Rawhide rebase
by Jaroslav Reznik
Greetings,
This e-mail is intended to inform you about the upcoming Bugzilla changes
happening March 3, 2015 (Rawhide bug rebase) and what you need to do, if anything.
We will be automatically changing the version for most rawhide bugs to Fedora 22.
This will result in regular bugs reported against rawhide during the Fedora 22
development cycle being changed to version ‘22' instead of their current
assignment, ‘rawhide’. This is to align with the branching of Fedora 22 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. These will stay open as rawhide bugs indefinitely.
If you do not want your bugs changed to version ‘22‘, 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
8 years, 9 months
F22 Self Contained Change: LXQt
by Jaroslav Reznik
= Proposed Self Contained Change: LXQt =
https://fedoraproject.org/wiki/Changes/LXQt
Change owner(s): Helio Chissini de Castro <heliocastro(a)fedoraproject.org>,
Christoph Wickert <cwickert(a)fedoraproject.org>
Package the LXQt desktop Environment for Fedora.
* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *
== Detailed Description ==
LXQt [1] is the Qt port and the upcoming version of LXDE [2], the Lightweight
Desktop Environment. It is the product of the merge between the LXDE-Qt and
the Razor-qt projects: A lightweight, modular, blazing-fast and user-friendly
desktop environment.
== Scope ==
* Proposal owners: LXQt packages already approved and in the system.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
[1] http://lxqt.org/
[2] https://fedoraproject.org/wiki/LXDE
8 years, 9 months
F22 System Wide Change: Legacy implementations of the Java platform in Fedora
by Jaroslav Reznik
= Proposed System Wide Change: Legacy implementations of the Java platform in
Fedora =
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora
Change owner(s): Jiri Vanek <jvanek(a)redhat.com>
Currently Fedora supports one main Java runtime and Java Development Kit (JDK)
and from time to time one future JDK as a tech preview. This change should be
set of rules, which will enable community to maintain legacy JDKs. Please
note, people are bugging main JDK maintainers pretty often with this, and to
allow them to maintain legacy JDKs is a step in right direction.
* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *
== Detailed Description ==
This is no real work proposal. The result of this proposal is set of rules,
which will allow community maintainers to pack any legacy jdk and will be
ensuring that this JDKs will not conflict by any other JDK and will smoothly
integrate to system. The results are summarized here, and pledged for
discussion until final resolution is done.
=== Proposed rules ===
0. '''Main JDK maintainers are not never ever responsible for any legacy jdk.
This must remain clear'''
==== option one - introducing new packages - preferred ====
1. main jdk is proclaimed as dead as it was until now. The new jdk is derived
as new package prviousName-legacy
1. so from killed java-1.7.0-openjdk will become new package java-1.7.0-
openjdk-legacy
2. next main jdk do Obsolete previous one as usually
2. new package '''must''' not do any virtual provides (aka java,java-devel)...
(protection against random pull by as dependence)
1. it provides only itself by name
3 its priority '''must''' be kept on less digits (right now it would be 5)
then main jdk (protection against winning in alternatives after update)
1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084
are '''mandatory'''
4. at least one of the main-jdk's members '''must''' be set as comaintainer
(to watch the commits and save the world if necessary)
5. new package '''should''' to follow both original jdk (ideally not change
at all (except source updates and necessary)) and current main jdk as close as
possibly
1. here it requires some common sense and a lot of testing if integration
with system is as expected
6. as it is generally not new package, the review process '''should''' be only
formal - to know maintainer and to create cvs repo
1. this is quite important, otherwise the new maintainer can become really
frustrated, and we are forcing the "dead" package over"orpahned" so the full
review (especially in alignment with rule 5) really should not be forced.
2. on the contrary, rules agreed here '''must''' be checked. (even the
number 5)
7. all depending packages '''must''' keep requiring java-headless or java (and
BuildRequires java-devel). Requirements on any exact jdk - or even worse on
any exact legacy jdk are forbidden and needs FESCO exception.
This option is forcing maintainers to fight with the name x current setup of
alternatives. However, the work should be minimal. But it makes the update
path pretty clear and it keeps users well protected against legacy jdk.
==== option two - orphaning legacy jdks and ensure update path ====
1. main JDK is only orphaned when new main JDK landed
1. it do '''not''' Obsolate previous jdk
2. other rules (2-7) are same
This is making life of legacy JDK maintainers a bit simpler. But I don't know,
how to ensure proper "obsolete" implementation in this case.
== Scope ==
* Proposal owners: are responsible for initial setup of those guidelines.
The FESCO, the owners and pssible legacy JDKs maintainers have to agree on
those rules. New legacy JDK can be then added anytime in Fedora lifecycle.
* Other developers: no developers
* Release engineering: in ideal case, no release engineer needed
* Policies and guidelines: The proposal may split to proposal and "Legacy JDKs
in Fedora guidelines" pages
8 years, 9 months
Planned Outage: pkgs.fedoraproject.org - 2015-02-19 09:00 UTC
by Kevin Fenzi
Planned Outage: Migration to gitolite3 - 2015-02-19 09:00 UTC
There will be an outage starting at 2015-02-19 09:00 UTC, 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 '2015-02-19 09:00 UTC'
Reason for outage: We will be upgrading our dist-git setup from
gitolite2 to gitolite3 and from RHEL6 to RHEL7. The ssh host keys
should be preserved in this migration. Uploads to lookaside cache,
commits or checkouts of pkgs git and official builds that use git will
be down during the outage.
Affected Services:
Buildsystem - http://koji.fedoraproject.org/
GIT / Source Control - pkgs.fedoraproject.org
Secondary Architectures
Unaffected Services:
Ask Fedora - http://ask.fedoraproject.org/
Badges - https://badges.fedoraproject.org/
BFO - http://boot.fedoraproject.org/
Blockerbugs - https://qa.fedoraproject.org/blockerbugs/
Bodhi - https://admin.fedoraproject.org/updates/
Darkserver - https://darkserver.fedoraproject.org/
DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org,
ns04.fedoraproject.org, ns05.fedoraproject.org
Docs - http://docs.fedoraproject.org/
Elections - https://admin.fedoraproject.org/voting
Email system
Fedmsg busmon - http://apps.fedoraproject.org/busmon
Fedora Account System - https://admin.fedoraproject.org/accounts/
Fedora Community - https://admin.fedoraproject.org/community/
Fedora Calendar - https://apps.fedoraproject.org/calendar/
Fedora Hosted - https://fedorahosted.org/
Fedora OpenID - https://id.fedoraproject.org/
Fedora People - http://fedorapeople.org/
Main Website - http://fedoraproject.org/
Mirror List - https://mirrors.fedoraproject.org/
Mirror Manager - https://admin.fedoraproject.org/mirrormanager/
Package Database - https://admin.fedoraproject.org/pkgdb/
QA Services
Spins - http://spins.fedoraproject.org/
Start - http://start.fedoraproject.org/
Torrent - http://torrent.fedoraproject.org/
Wiki - http://fedoraproject.org/wiki/
Contact Information: pingou, kevin
Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4651
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
8 years, 9 months
Fedora 22 Changes Completion deadline in one week - 2015-02-24
by Jaroslav Reznik
Greetings!
Fedora 22 Change Checkpoint: Completion deadline (testable) is in
one week - 2015-02-24 [1] and we're getting closer to this date.
Other important milestones are scheduled for this date:
* Alpha Freeze
* Software String Freeze
* Bodhi activation point
At this point, all accepted changes should be substantially complete,
and testable. Additionally, if a change is to be enabled by default,
it must be so enabled at Change Completion deadline.
Change tracking bug should be set to the MODIFIED state to indicate
it achieved completeness.
Fedora 22 is strictly time based release and we want to adhere to the
schedule. Incomplete and non testable Changes will be reported to
FESCo for 2015-02-25 meeting. Contingency plan for System Wide Changes,
if planned for Alpha (or in case of serious doubts regarding Change
completion), will be activated.
[1] https://fedoraproject.org/wiki/Releases/22/Schedule
Jaroslav
8 years, 9 months
Fedora 22 Mass Branching
by Peter Robinson
Hi All,
Fedora 22 has been branched, please be sure to do a git pull --rebase to
pick up the new branch, as an additional reminder rawhide/f23 has had
inheritance cut off from previous releases, so this means that
anything you do for f22 you also have to do in the master branch and do
a build there. This is the same as we did for previous Fedora releases
Peter
8 years, 9 months