Hi all,
As many of you know, I've been gone half the summer. I'm back now since Monday though and just in time for GNOME 3.30.0 :)
We are quite a bit behind with the builds, like half of GNOME is still at 3.28.x or at various stages of 3.29.x snapshots, so there's quite a bit of catching up to do.
I just requested a f29-gnome side tag and will be commencing 3.30.0 builds shortly. When the builds are done, I'll try to collect all the builds in a single Bodhi megaupdate as usual. Please use 'fedpkg build --target f29-gnome' if you are helping with builds, and I'll pick up anything that is tagged with f29-gnome in koji.
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29 Beta, I guess it may be too late for that. Any opinions from QA here?
There's also a few 3.30.0 builds already submitted separately into Bodhi. I may try to collect those to the megaupdate as well, not sure yet. Let's see how things go :)
Thanks, Kalev
On Wed, Sep 5, 2018 at 11:12 AM Kalev Lember kalevlember@gmail.com wrote:
Hi all,
As many of you know, I've been gone half the summer. I'm back now since Monday though and just in time for GNOME 3.30.0 :)
We are quite a bit behind with the builds, like half of GNOME is still at 3.28.x or at various stages of 3.29.x snapshots, so there's quite a bit of catching up to do.
I just requested a f29-gnome side tag and will be commencing 3.30.0 builds shortly. When the builds are done, I'll try to collect all the builds in a single Bodhi megaupdate as usual. Please use 'fedpkg build --target f29-gnome' if you are helping with builds, and I'll pick up anything that is tagged with f29-gnome in koji.
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29 Beta, I guess it may be too late for that. Any opinions from QA here?
There's also a few 3.30.0 builds already submitted separately into Bodhi. I may try to collect those to the megaupdate as well, not sure yet. Let's see how things go :)
I'd be *strongly* disinclined to give a Freeze Exception for a GNOME mega-update. There's just far too much that could go wrong. Please plan to land the mega-update in updates-testing once the Freeze lifts. U-T is enabled by default on the Beta, so people will pick it up on their first post-install update anyway.
On Wed, 5 Sep 2018 at 16:19, Stephen Gallagher sgallagh@redhat.com wrote:
I'd be *strongly* disinclined to give a Freeze Exception for a GNOME mega-update.
So you'd rather we ship GA with early pre-release builds of GNOME that have had little-to-no testing? From a downstream point of view I'm not going to fix things found by Fedora QA in 3.29.4 when a stable 3.30.0 exists with those fixes.
Richard.
As many of you know, I've been gone half the summer. I'm back now since Monday though and just in time for GNOME 3.30.0 :)
We are quite a bit behind with the builds, like half of GNOME is still at 3.28.x or at various stages of 3.29.x snapshots, so there's quite a bit of catching up to do.
I just requested a f29-gnome side tag and will be commencing 3.30.0 builds shortly. When the builds are done, I'll try to collect all the builds in a single Bodhi megaupdate as usual. Please use 'fedpkg build --target f29-gnome' if you are helping with builds, and I'll pick up anything that is tagged with f29-gnome in koji.
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29 Beta, I guess it may be too late for that. Any opinions from QA here?
There's also a few 3.30.0 builds already submitted separately into Bodhi. I may try to collect those to the megaupdate as well, not sure yet. Let's see how things go :)
I'd be *strongly* disinclined to give a Freeze Exception for a GNOME mega-update. There's just far too much that could go wrong. Please plan to land the mega-update in updates-testing once the Freeze lifts. U-T is enabled by default on the Beta, so people will pick it up on their first post-install update anyway.
Ultimately by declining it now all we're doing is pushing out the pain, if any, to post beta which IMO is even worse given we're then deferring it to GA freeze which is even worse!
Also there has been a precedent in the past for putting this in, whether that is right or not I have no opinion.
Peter
On Wed, Sep 5, 2018 at 8:49 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 5, 2018 at 11:12 AM Kalev Lember kalevlember@gmail.com wrote:
Hi all,
As many of you know, I've been gone half the summer. I'm back now since Monday though and just in time for GNOME 3.30.0 :)
We are quite a bit behind with the builds, like half of GNOME is still at 3.28.x or at various stages of 3.29.x snapshots, so there's quite a bit of catching up to do.
I just requested a f29-gnome side tag and will be commencing 3.30.0 builds shortly. When the builds are done, I'll try to collect all the builds in a single Bodhi megaupdate as usual. Please use 'fedpkg build --target f29-gnome' if you are helping with builds, and I'll pick up anything that is tagged with f29-gnome in koji.
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29 Beta, I guess it may be too late for that. Any opinions from QA here?
There's also a few 3.30.0 builds already submitted separately into Bodhi. I may try to collect those to the megaupdate as well, not sure yet. Let's see how things go :)
I'd be *strongly* disinclined to give a Freeze Exception for a GNOME mega-update. There's just far too much that could go wrong. Please plan to land the mega-update in updates-testing once the Freeze lifts. U-T is enabled by default on the Beta, so people will pick it up on their first post-install update anyway.
Please don't stop this update. There will be few required fixes in this megaupdate which we need early to test.
Parag.
On Wed, 2018-09-05 at 22:15 +0530, Parag Nemade wrote:
On Wed, Sep 5, 2018 at 8:49 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 5, 2018 at 11:12 AM Kalev Lember kalevlember@gmail.com wrote:
Hi all,
As many of you know, I've been gone half the summer. I'm back now since Monday though and just in time for GNOME 3.30.0 :)
We are quite a bit behind with the builds, like half of GNOME is still at 3.28.x or at various stages of 3.29.x snapshots, so there's quite a bit of catching up to do.
I just requested a f29-gnome side tag and will be commencing 3.30.0 builds shortly. When the builds are done, I'll try to collect all the builds in a single Bodhi megaupdate as usual. Please use 'fedpkg build --target f29-gnome' if you are helping with builds, and I'll pick up anything that is tagged with f29-gnome in koji.
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29 Beta, I guess it may be too late for that. Any opinions from QA here?
There's also a few 3.30.0 builds already submitted separately into Bodhi. I may try to collect those to the megaupdate as well, not sure yet. Let's see how things go :)
I'd be *strongly* disinclined to give a Freeze Exception for a GNOME mega-update. There's just far too much that could go wrong. Please plan to land the mega-update in updates-testing once the Freeze lifts. U-T is enabled by default on the Beta, so people will pick it up on their first post-install update anyway.
Please don't stop this update. There will be few required fixes in this megaupdate which we need early to test.
There is a precedent for accepting this kind of update during freeze, but GNOME is usually in a more organized state to start with (i.e. we're usually going from something like an organized set of .91 builds to an organized set of .0 builds), so I suspect the danger of destabilizing the Beta is slightly higher. The earlier the update can be put together, the less unhappy I'd be to accept it wholesale through the freeze. Note that Go/No-Go is scheduled for next Thursday.
To make sure everyone's on the same page, if we do *not* accept the update for the Beta, then by default those who install the Beta will get it on their first system update after installing (as updates- testing is enabled by default for pre-releases). Thus it will still certainly be testable.
The decision to be made is basically "do the benefits of having the 3.30.0 builds actually in the Beta, in terms of making the live image and first boot environment work better, outweigh the risks that they will somehow cause issues for the compose process or contain undetected critical bugs worse than those in the current builds". The more runway we have to test the compose process and the composed artifacts, the happier I'd be with saying the benefits will likely outweigh the drawbacks.
On Wed, 2018-09-05 at 11:19 -0400, Stephen Gallagher wrote:
On Wed, Sep 5, 2018 at 11:12 AM Kalev Lember kalevlember@gmail.com wrote:
Hi all,
As many of you know, I've been gone half the summer. I'm back now since Monday though and just in time for GNOME 3.30.0 :)
We are quite a bit behind with the builds, like half of GNOME is still at 3.28.x or at various stages of 3.29.x snapshots, so there's quite a bit of catching up to do.
I just requested a f29-gnome side tag and will be commencing 3.30.0 builds shortly. When the builds are done, I'll try to collect all the builds in a single Bodhi megaupdate as usual. Please use 'fedpkg build --target f29-gnome' if you are helping with builds, and I'll pick up anything that is tagged with f29-gnome in koji.
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29 Beta, I guess it may be too late for that. Any opinions from QA here?
There's also a few 3.30.0 builds already submitted separately into Bodhi. I may try to collect those to the megaupdate as well, not sure yet. Let's see how things go :)
I'd be *strongly* disinclined to give a Freeze Exception for a GNOME mega-update. There's just far too much that could go wrong. Please plan to land the mega-update in updates-testing once the Freeze lifts. U-T is enabled by default on the Beta, so people will pick it up on their first post-install update anyway.
There is no need to wait "for the Freeze [to] lift" to land this or any update in updates-testing. The freeze applies only to the 'stable' repository: the freeze prevents packages being moved *from* updates- testing to 'stable' (without approval via FE/blocker process). Packages can be submitted to, and land in, updates-testing at any time throughout the cycle.
On Wed, Sep 05, 2018 at 05:04:46PM +0200, Kalev Lember wrote:
We are quite a bit behind with the builds, like half of GNOME is still at 3.28.x or at various stages of 3.29.x snapshots, so there's quite a bit of catching up to do.
We used to always have a Change submitted for the GNOME update, but that stopped, I assume because it felt like kind of rote bureaucracy rather than helpful, since it was basically the same every time. Maybe it's useful after all to help keep communications open for situations like this?
On Wed, Sep 5, 2018 at 1:50 PM Matthew Miller mattdm@fedoraproject.org wrote:
We used to always have a Change submitted for the GNOME update, but that stopped, I assume because it felt like kind of rote bureaucracy rather than helpful, since it was basically the same every time. Maybe it's useful after all to help keep communications open for situations like this?
It may come as no surprise given my role, but I'm in favor of continuing to submit Change proposals for GNOME updates and similar. I'd be open to a "shortcut" version of the Change process that essentially says "hey, we're doing this again". But this way we'd get visibility across teams and externally. For better or for worse, our Change list is a starting point for marketing and PR, so it's beneficial to have these sorts of things visible externally, too.
On Wed, Sep 05, 2018 at 04:47:32PM -0400, Ben Cotton wrote:
I'd be open to a "shortcut" version of the Change process that essentially says "hey, we're doing this again". But this way we'd get visibility across teams and externally. For better or for worse, our Change list is a starting point for marketing and PR, so it's beneficial to have these sorts of things visible externally, too.
The self-contained changes _should_ basically serve as "shortcuts", but it does seem like there are a number of these "new version of X" changes that could benefit from an even more short version, including one-time FESCo approval rather than needing to be re-upped as long as nothing significant changes?
On Wed, Sep 05, 2018 at 04:47:32PM -0400, Ben Cotton wrote:
On Wed, Sep 5, 2018 at 1:50 PM Matthew Miller mattdm@fedoraproject.org wrote:
We used to always have a Change submitted for the GNOME update, but that stopped, I assume because it felt like kind of rote bureaucracy rather than helpful, since it was basically the same every time. Maybe it's useful after all to help keep communications open for situations like this?
It may come as no surprise given my role, but I'm in favor of continuing to submit Change proposals for GNOME updates and similar. I'd be open to a "shortcut" version of the Change process that essentially says "hey, we're doing this again". But this way we'd get visibility across teams and externally. For better or for worse, our Change list is a starting point for marketing and PR, so it's beneficial to have these sorts of things visible externally, too.
+1
For recurrent Changes, I think it is totally OK to just copy text Change page, update the numbers and dates, and resubmit.
Zbyszek
On Wed, Sep 5, 2018 at 9:04 AM, Kalev Lember kalevlember@gmail.com wrote:
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29 Beta, I guess it may be too late for that. Any opinions from QA here?
If 3.29 is not what GNOME folks had ever wanted to ship in the Beta, why are we hearing about it one week before go/nogo? The schedule has been published for what, 9 months? *shrug*
I do not like the idea that it is a QA decision to enforce or relax the schedule. This isn't what freeze exception is intended for. It's intended for abrasive, ugly, or annoying bugs, that simply do not qualify as release blocking and the fix for which is unlikely to itself become a blocker. There is no information presented for QA to even assess this question as it stands.
The next blocker and freeze exception review is on Monday. We cannot even get a release candidate until all known blockers are cleared. The earliest we likely see any kind of compose with 3.30 would be maybe 1800UTC on Tuesday? Haha! Not even two days of testing? That's comical.
My opinion, since there are few facts to go on to overcome the burden stated in a written process and schedule for some time, is -1 FE. If it was important enough to get 3.30 on actual Beta installation media, it needed to be done before freeze. Not depend on a freeze exception. That is definitely not how things are supposed to work.
On Wed, 2018-09-05 at 12:14 -0600, Chris Murphy wrote:
On Wed, Sep 5, 2018 at 9:04 AM, Kalev Lember kalevlember@gmail.com wrote:
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29 Beta, I guess it may be too late for that. Any opinions from QA here?
If 3.29 is not what GNOME folks had ever wanted to ship in the Beta, why are we hearing about it one week before go/nogo? The schedule has been published for what, 9 months? *shrug*
I do not like the idea that it is a QA decision to enforce or relax the schedule. This isn't what freeze exception is intended for. It's intended for abrasive, ugly, or annoying bugs, that simply do not qualify as release blocking and the fix for which is unlikely to itself become a blocker. There is no information presented for QA to even assess this question as it stands.
Neither the blocker / FE process, nor its decisions, are owned by QA. By policy it is a joint effort between QA, release engineering and development.
The next blocker and freeze exception review is on Monday. We cannot even get a release candidate until all known blockers are cleared. The earliest we likely see any kind of compose with 3.30 would be maybe 1800UTC on Tuesday?
Freeze exceptions can be granted out-of-band with voting in-bug. We've granted two today already.
Haha! Not even two days of testing? That's comical.
My opinion, since there are few facts to go on to overcome the burden stated in a written process and schedule for some time, is -1 FE. If it was important enough to get 3.30 on actual Beta installation media, it needed to be done before freeze. Not depend on a freeze exception. That is definitely not how things are supposed to work.
As it happens, it is how things have been working, though. We've granted freeze exceptions for GNOME megaupdates for many of the last several releases (I can go back and get precise numbers if you like).
Notably, I can't recall a single instance where they broke the world. This is not something I can say about a lot of packages, so I think the desktop team deserves some credit and trust for that.
On Wed, Sep 5, 2018 at 6:59 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2018-09-05 at 12:14 -0600, Chris Murphy wrote:
My opinion, since there are few facts to go on to overcome the burden stated in a written process and schedule for some time, is -1 FE. If it was important enough to get 3.30 on actual Beta installation media, it needed to be done before freeze. Not depend on a freeze exception. That is definitely not how things are supposed to work.
As it happens, it is how things have been working, though. We've granted freeze exceptions for GNOME megaupdates for many of the last several releases (I can go back and get precise numbers if you like).
That's OK. Besides, there's some chance I have voted +1 FE for a GNOME megaupdate, not least of which is because:
Notably, I can't recall a single instance where they broke the world. This is not something I can say about a lot of packages, so I think the desktop team deserves some credit and trust for that.
For sure. But that is orthogonal to freeze exception. It's like using FE as some kind of Good Job sticker.
And we all know there is increased probability that blocker bugs are not found or are found later than otherwise, because of diverted attention toward testing the megaupdate. There is no way of predicting or assessing this, but logically it's true. And so this particular usage of freeze exception ends up having more in common with craps, than a well deserved Good Job sticker.
On Thu, 2018-09-06 at 10:13 -0600, Chris Murphy wrote:
On Wed, Sep 5, 2018 at 6:59 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2018-09-05 at 12:14 -0600, Chris Murphy wrote:
My opinion, since there are few facts to go on to overcome the burden stated in a written process and schedule for some time, is -1 FE. If it was important enough to get 3.30 on actual Beta installation media, it needed to be done before freeze. Not depend on a freeze exception. That is definitely not how things are supposed to work.
As it happens, it is how things have been working, though. We've granted freeze exceptions for GNOME megaupdates for many of the last several releases (I can go back and get precise numbers if you like).
That's OK. Besides, there's some chance I have voted +1 FE for a GNOME megaupdate, not least of which is because:
Notably, I can't recall a single instance where they broke the world. This is not something I can say about a lot of packages, so I think the desktop team deserves some credit and trust for that.
For sure. But that is orthogonal to freeze exception. It's like using FE as some kind of Good Job sticker.
I wouldn't say it's orthogonal, at all. It's a significant factor. It's true to say that we shouldn't grant something FE status *solely because* we don't think it's likely to break anything terribly. It's not *sufficient* justification in itself. But if there is, let's say, a plausible case for "there are some good reasons to let this in Beta" but *also* a plausible case for "...but it's kinda late and we don't absolutely *need* it and it's change!", then the track record of that team and that kind of change absolutely does factor into whether I'm likely to vote +1.
And we all know there is increased probability that blocker bugs are not found or are found later than otherwise, because of diverted attention toward testing the megaupdate. There is no way of predicting or assessing this, but logically it's true. And so this particular usage of freeze exception ends up having more in common with craps, than a well deserved Good Job sticker.
Eh. I don't think more people testing Workstation, for whatever reason, is really going to be a *bad* thing. Maybe the increased attention causes us to find a blocker we'd otherwise have missed?
----- Original Message -----
On Wed, Sep 5, 2018 at 9:04 AM, Kalev Lember kalevlember@gmail.com wrote:
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29 Beta, I guess it may be too late for that. Any opinions from QA here?
If 3.29 is not what GNOME folks had ever wanted to ship in the Beta, why are we hearing about it one week before go/nogo? The schedule has been published for what, 9 months? *shrug*
GNOME has been releasing every 6 months on pretty much the same dates for more than 10 years, and Fedora's schedule is modelled after GNOME's for the purpose of getting things like GNOME, and other bi-yearly time-based releases into Fedora. So Fedora knows well what schedule it needs to adopt to get a .0 version of GNOME into the beta.
With GNOME 3.30 having been released yesterday, on schedule, I'm not sure how either the Fedora packagers or the upstream could have done things differently.
As a sidenote, this tone of discourse is frankly getting old. GNOME aren't there to spite you.
On Thu, Sep 6, 2018 at 9:01 AM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On Wed, Sep 5, 2018 at 9:04 AM, Kalev Lember kalevlember@gmail.com wrote:
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29 Beta, I guess it may be too late for that. Any opinions from QA here?
If 3.29 is not what GNOME folks had ever wanted to ship in the Beta, why are we hearing about it one week before go/nogo? The schedule has been published for what, 9 months? *shrug*
GNOME has been releasing every 6 months on pretty much the same dates for more than 10 years, and Fedora's schedule is modelled after GNOME's for the purpose of getting things like GNOME, and other bi-yearly time-based releases into Fedora. So Fedora knows well what schedule it needs to adopt to get a .0 version of GNOME into the beta.
With GNOME 3.30 having been released yesterday, on schedule, I'm not sure how either the Fedora packagers or the upstream could have done things differently.
That is a very reasonable response but also doesn't actually answer the question. The schedules have been misaligned for months, so why only bring up that misalignment now and characterize it as if it's a big deal? There is an incongruency happening. It does present the appearance GNOME expects a persistent and on-going exception for beta freeze. Is that a fair characterization?
If the schedules themselves do not align and will not ever align and it's important for .0 version of GNOME to be in the beta, I'd like to see some way of making that happen that does not involve the roll of the dice that is freeze exception as applied to something as complex and massive as *GNOME megaupdate* sounds and is and really only a few people could possibly properly assess, which isn't how FE works.
Fedora folks have been testing 3.29 for weeks now. Fedora people haven't been testing 3.30 because it's not really available to test. So I think it's reasonable for a GNOME specific change to explicitly state a request and expectation for a beta freeze exception for every Fedora release so that a .0 lands in the beta, and see if FESCo thinks that's sane and accepts the change.
But such as it is, the schedule is the schedule, warts and all, and freeze exception is for bugs. It's not for realigning misaligned schedules.
As a sidenote, this tone of discourse is frankly getting old. GNOME aren't there to spite you.
Never said that nor implied it. I asked two questions. There's tone in asking questions?
On Thu, 2018-09-06 at 10:41 -0600, Chris Murphy wrote:
Fedora folks have been testing 3.29 for weeks now. Fedora people haven't been testing 3.30 because it's not really available to test. So I think it's reasonable for a GNOME specific change to explicitly state a request and expectation for a beta freeze exception for every Fedora release so that a .0 lands in the beta, and see if FESCo thinks that's sane and accepts the change.
Uh, to be clear here: you do know that 3.29 is the development series for 3.30, right? It's not a sudden major release jump. Effectively what we have right now is more or less 3.30 rc0-and-a-bit; the proposal is to go from that to 3.30 stable.
On Thu, Sep 6, 2018 at 12:33 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2018-09-06 at 10:41 -0600, Chris Murphy wrote:
Fedora folks have been testing 3.29 for weeks now. Fedora people haven't been testing 3.30 because it's not really available to test. So I think it's reasonable for a GNOME specific change to explicitly state a request and expectation for a beta freeze exception for every Fedora release so that a .0 lands in the beta, and see if FESCo thinks that's sane and accepts the change.
Uh, to be clear here: you do know that 3.29 is the development series for 3.30, right? It's not a sudden major release jump. Effectively what we have right now is more or less 3.30 rc0-and-a-bit; the proposal is to go from that to 3.30 stable.
I'm aware.
But it's also striking me as a big deal that's no big deal, like we're playing a game of upping the vaguarity ante.
On Thu, Sep 6, 2018 at 12:33 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2018-09-06 at 10:41 -0600, Chris Murphy wrote:
Fedora folks have been testing 3.29 for weeks now. Fedora people haven't been testing 3.30 because it's not really available to test. So I think it's reasonable for a GNOME specific change to explicitly state a request and expectation for a beta freeze exception for every Fedora release so that a .0 lands in the beta, and see if FESCo thinks that's sane and accepts the change.
Uh, to be clear here: you do know that 3.29 is the development series for 3.30, right? It's not a sudden major release jump. Effectively what we have right now is more or less 3.30 rc0-and-a-bit; the proposal is to go from that to 3.30 stable.
I'm aware.
But it's also striking me as a big deal that's no big deal, like we're playing a game of upping the vaguarity ante.
Nope, completely not, we do this most release cycles and not just gnome... it also doesn't affect any of the artifacts that don't ship gnome compents.
Having been involved in this process for so long I'm kind of surprised the biggest deal of all of this is that this is a "big deal"... the fact is post beta we open up the flood gates again so this is going to be there so IMO I'd sooner it now where we can get people that do a "quick fly by beta live CD boot" before they upgrade and catch the issues now than at GA :)
OK, builds done and the 3.30.0 megaupdate is in Bodhi now and queued for updates-testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-85d637c544
----- Original Message -----
From: "Kalev Lember" kalevlember@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Cc: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Saturday, September 8, 2018 11:13:26 AM Subject: Re: GNOME 3.30.0 megaupdate
OK, builds done and the 3.30.0 megaupdate is in Bodhi now and queued for updates-testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-85d637c544
-- Kalev _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
Thanks, I will start testing it right away! :)
On 09/08/2018 07:43 AM, Kalev Lember wrote:
OK, builds done and the 3.30.0 megaupdate is in Bodhi now and queued for updates-testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-85d637c544
Just as a quick heads up, this was accepted as a Freeze Exception in yesterday's blocker review meeting. We've tracked down a few regressions in the initial megaupdate and (hopefully) fixed those, and I think it should be good to go to stable soon. Bodhi karma and testing appreciated if you're running F29 with updates-testing enabled.
Also if you've already added karma, please do it again as the edits reset all the +1's added so far.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-85d637c544
desktop@lists.fedoraproject.org
-
Adam Williamson -
Bastien Nocera -
Ben Cotton -
Chris Murphy -
Kalev Lember -
Matthew Miller -
Parag Nemade -
Peter Robinson -
Richard Hughes -
Stephen Gallagher -
Sumantro Mukherjee -
Zbigniew Jędrzejewski-Szmek