Do we have system wide changes still to file for F23?
ISTM we have a few contenders that are not yet listed in the proposed changes[1] list:
* Integrating distro upgrade * D-Bus activation in gnome-session? (does this affect non-GNOME?) * Boxes import OVF/OVA (iff. this affects Fedora deliverables, either new requirements, or which can be dropped) * Live USB changes -- since this affects e.g. docs/websites, possibly a marketing angle
[1] https://fedoraproject.org/wiki/Releases/23/ChangeSet
-- Paul
----- Forwarded message from Jan Kurik jkurik@redhat.com -----
Date: Tue, 16 Jun 2015 08:39:19 -0400 (EDT) From: Jan Kurik jkurik@redhat.com To: devel-announce@lists.fedoraproject.org Subject: Submission deadline for Changes of Fedora 23 X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF38 (Linux)/8.0.6_GA_5922) X-BeenThere: devel-announce@lists.fedoraproject.org
Hi everyone!
Changes submission deadline for Fedora 23 [1] is coming pretty soon - in one week on June 23rd. With Alpha release in August. Please, submit your System Wide Changes by this deadline, earlier better. As the deadline mainly applies for System Wide changes it is always good to have most of Self Contained Changes proposed as well.
In case you'll need any help with your Change proposals, feel free to contact me.
Best Regards, Jan
[1] https://fedoraproject.org/wiki/Releases/23/Schedule
On Tue, Jun 16, 2015 at 12:05:51PM -0400, Paul W. Frields wrote:
ISTM we have a few contenders that are not yet listed in the proposed changes[1] list:
- Integrating distro upgrade
This one has nice marketing potential — easy release-to-release upgrades instead of a rolling release (or LTS, for that matter).
On Tue, 2015-06-16 at 12:05 -0400, Paul W. Frields wrote:
Do we have system wide changes still to file for F23?
ISTM we have a few contenders that are not yet listed in the proposed changes[1] list:
- Integrating distro upgrade
Sadly, I don't have anybody free to work on this in the short term. We can probably pick this up in August, but by then it may be too late for F23.
- D-Bus activation in gnome-session? (does this affect non-GNOME?)
Not really that interesting. It is an internal change to session infrastructure.
- Boxes import OVF/OVA (iff. this affects Fedora deliverables, either new requirements, or which can be dropped)
Kalev started working on this, but I had to pull him off to help with something else - it may still happen for GNOME 3.18, if things play out perfectly.
- Live USB changes -- since this affects e.g. docs/websites, possibly a marketing angle
This one is covered here:
https://fedoraproject.org/wiki/Changes/LiveUsbCreatorFacelift
One more change that we had planned but didn't get to take effect yet is to switch to Wayland by default.
On Tue, Jun 16, 2015 at 01:22:24PM -0400, Matthias Clasen wrote:
ISTM we have a few contenders that are not yet listed in the proposed changes[1] list:
- Integrating distro upgrade
Sadly, I don't have anybody free to work on this in the short term. We can probably pick this up in August, but by then it may be too late for F23.
It certainly would be nice for upgrades to be testable by the alpha release, mid August, but maybe that could be pushed back to a beta target? Seems kind of risky.
What's the fallback option here? Find someone to keep FedUp working for one more release?
One more change that we had planned but didn't get to take effect yet is to switch to Wayland by default.
That'd certainly be big in the Linux press. Do you think it'll be ready?
On Tue, Jun 16, 2015 at 12:54:17PM -0500, Michael Catanzaro wrote:
On Tue, 2015-06-16 at 13:28 -0400, Matthew Miller wrote:
What's the fallback option here? Find someone to keep FedUp working for one more release?
I believe there is a dnf upgrade plugin to replace fedup.
Will did that as a proof of concept, but I'm not sure whether that's meant to be a supportable solution.
On Fri, 2015-06-19 at 12:28 -0400, Paul W. Frields wrote:
On Tue, Jun 16, 2015 at 12:54:17PM -0500, Michael Catanzaro wrote:
On Tue, 2015-06-16 at 13:28 -0400, Matthew Miller wrote:
What's the fallback option here? Find someone to keep FedUp working for one more release?
I believe there is a dnf upgrade plugin to replace fedup.
Will did that as a proof of concept, but I'm not sure whether that's meant to be a supportable solution.
It's a much better solution than *current* fedup, but yeah, it's really just a proof-of-concept.
The concept is that System Upgrades should be done as follows:
1) Prepare an Offline System Update[1], with $releasever=NEW_VERSION 2) Run the offline system update
...which means system upgrades are really just big updates. So it makes sense that the update tools should handle them, not a special tool maintained by the installer team.
So, I'm trying to get support for this stuff into DNF itself[2], but if the DNF team can't/won't support system upgrades, I'd still recommend dnf-plugin-fedup over the existing fedup.
-w
[1] http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates [2] https://github.com/rpm-software-management/dnf/pull/281
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/%C2%A0%C2%A0%C2%A0-%C2%A0%C2%A0-%C2%A0%C2%A0-%C2%A0%C2%A0-... The open source story continues to grow: http://opensource.com
On Thu, Jun 25, 2015 at 12:01:45 -0400, Will Woods wwoods@redhat.com wrote:
So, I'm trying to get support for this stuff into DNF itself[2], but if the DNF team can't/won't support system upgrades, I'd still recommend dnf-plugin-fedup over the existing fedup.
Having done a few mass updates using DNF over the last few months, I have noticed that their depsolver handles complicated messes better than yum did, and can proceed with partial updates where yum used fail entirely.
On Fri, 2015-06-26 at 11:32 -0500, Bruno Wolff III wrote:
Having done a few mass updates using DNF over the last few months, I have noticed that their depsolver handles complicated messes better than yum did, and can proceed with partial updates where yum used fail entirely.
...that's really more about policy than any technical reason, though: DNF `upgrade` is roughly equivalent to `yum upgrade --skip-broken`.
If you use `dnf upgrade --best` you get the yum default behavior, which will fail when there are broken deps - just like yum did.
-w
On Fri, Jun 26, 2015 at 13:26:01 -0400, Will Woods wwoods@redhat.com wrote:
On Fri, 2015-06-26 at 11:32 -0500, Bruno Wolff III wrote:
Having done a few mass updates using DNF over the last few months, I have noticed that their depsolver handles complicated messes better than yum did, and can proceed with partial updates where yum used fail entirely.
...that's really more about policy than any technical reason, though: DNF `upgrade` is roughly equivalent to `yum upgrade --skip-broken`.
If you use `dnf upgrade --best` you get the yum default behavior, which will fail when there are broken deps - just like yum did.
yum update --skip-broken sometimes fails in complicated cases and dnf update doesn't seem to. I thought I had seen a direct comparison with yum-deprecated, but I think --skip-broken wasn't being used on that system by default. But given I have seen yum fail to do any updates when --skip-broken was used even though there were updatable packages (which I updated with yum by specifying a subset of packages) and I have not seen this happen with dnf, I do think that dnf update will work in some cases where yum --skip-broken won't.
I have been disappointed in dnf update --best --allowerasing, as there seems to be some limitations (that I haven't figured out) on what it will erase and I end up having to manually erase packages that are pinning old versions of libraries, to get stuff to update.
On Tue, Jun 16, 2015 at 01:28:12PM -0400, Matthew Miller wrote:
On Tue, Jun 16, 2015 at 01:22:24PM -0400, Matthias Clasen wrote:
ISTM we have a few contenders that are not yet listed in the proposed changes[1] list:
- Integrating distro upgrade
Sadly, I don't have anybody free to work on this in the short term. We can probably pick this up in August, but by then it may be too late for F23.
It certainly would be nice for upgrades to be testable by the alpha release, mid August, but maybe that could be pushed back to a beta target? Seems kind of risky.
Given the Alpha freeze is end of July, that seems too late. I don't like the idea of skirting deadlines to get something that's historically touchy into a release at the last minute. I think what Matthias is saying is F24 makes a better target here. That's fine; I'm just looking to clarify.
What's the fallback option here? Find someone to keep FedUp working for one more release?
Either that, or we have people resort only to something like fedora-upgrade. Frankly, changing twice in the course of two releases won't build user confidence, though. cc'ing wwoods to see what he thinks.
On Fri, 2015-06-19 at 12:25 -0400, Paul W. Frields wrote:
On Tue, Jun 16, 2015 at 01:28:12PM -0400, Matthew Miller wrote:
On Tue, Jun 16, 2015 at 01:22:24PM -0400, Matthias Clasen wrote:
ISTM we have a few contenders that are not yet listed in the proposed changes[1] list:
- Integrating distro upgrade
Sadly, I don't have anybody free to work on this in the short term. We can probably pick this up in August, but by then it may be too late for F23.
Wait, are we talking about integrating distro upgrade support into PackageKit/gnome-software, or into DNF itself?
If the latter - i.e. there's nobody on the DNF team who will have time to work on integrating system-upgrade stuff - I'll happily volunteer to write patches...
What's the fallback option here? Find someone to keep FedUp working for one more release?
Either that, or we have people resort only to something like fedora-upgrade. Frankly, changing twice in the course of two releases won't build user confidence, though. cc'ing wwoods to see what he thinks.
I really don't think it'd be hard to move dnf-plugins-fedup into DNF and/or dnf-plugins-core. It's really, really simple - like ~240 lines of code, most of which is implementing offline updates + plymouth output support. (for comparison, fedup-0.9.2 is ~2450 lines of code.)
Also - doesn't fedora-upgrade require yum? Isn't that supposed to be deprecated?
-w
On Thu, 2015-06-25 at 12:37 -0400, Will Woods wrote:
Wait, are we talking about integrating distro upgrade support into PackageKit/gnome-software, or into DNF itself?
PackageKit and GNOME Software, but the earliest this might be working is for F23->F24 upgrades. For F22->F23 it will have to be your dnf plugin (or dnf if you move the code into dnf).
On Thu, 2015-06-25 at 12:34 -0500, Michael Catanzaro wrote:
On Thu, 2015-06-25 at 12:37 -0400, Will Woods wrote:
Wait, are we talking about integrating distro upgrade support into PackageKit/gnome-software, or into DNF itself?
PackageKit and GNOME Software, but the earliest this might be working is for F23->F24 upgrades. For F22->F23 it will have to be your dnf plugin (or dnf if you move the code into dnf).
That seems reasonable. And fedup's always been CLI-only, so I think it's OK if upgrades are still CLI-only for one more release.
-w
On Fri, Jun 19, 2015 at 6:25 PM, Paul W. Frields stickster@gmail.com wrote:
On Tue, Jun 16, 2015 at 01:28:12PM -0400, Matthew Miller wrote:
On Tue, Jun 16, 2015 at 01:22:24PM -0400, Matthias Clasen wrote:
ISTM we have a few contenders that are not yet listed in the proposed changes[1] list:
- Integrating distro upgrade
Sadly, I don't have anybody free to work on this in the short term. We can probably pick this up in August, but by then it may be too late for F23.
It certainly would be nice for upgrades to be testable by the alpha release, mid August, but maybe that could be pushed back to a beta target? Seems kind of risky.
Given the Alpha freeze is end of July, that seems too late. I don't like the idea of skirting deadlines to get something that's historically touchy into a release at the last minute. I think what Matthias is saying is F24 makes a better target here. That's fine; I'm just looking to clarify.
What's the fallback option here? Find someone to keep FedUp working for one more release?
Either that, or we have people resort only to something like fedora-upgrade. Frankly, changing twice in the course of two releases won't build user confidence, though. cc'ing wwoods to see what he thinks.
Well we could turn fedup into a script that runs the new dnf plugin under the hood to avoid that.
On Thu, 2015-06-25 at 20:02 +0200, drago01 wrote:
Well we could turn fedup into a script that runs the new dnf plugin under the hood to avoid that.
Are you volunteering to write the "fedup" wrapper script, or is that the famous Open Source "we"[1]? :D
To make the subtext of my previous messages plain:
* I am looking for help getting dnf-plugin-fedup upstreamed * fedup 0.9.x should be considered deprecated and unmaintained * I am not going to maintain dnf-plugin-fedup
I *will* do whatever work I can to get system-upgrade support into DNF, but beyond this transition I don't have time to work on it anymore.
Also, it just doesn't make sense to have upgrades and updates handled by separate tools, maintained by separate teams. It belongs with the rest of the packaging tools.
The DNF team doesn't seem to want to take ownership of the system -upgrade tool, though. So unless that changes: if you want upgrades to work well, someone else needs to step up and take ownership.
And I'm sorry, but it's not gonna be me.
-w
[1] which means either "somebody else" or "you", depending on context
desktop@lists.fedoraproject.org
-
Bruno Wolff III -
drago01 -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Paul W. Frields -
Will Woods