17:00:48 <jkurik> #startmeeting F25-Final-Go/No-Go-meeting
17:00:48 <zodbot> Meeting started Thu Nov 17 17:00:48 2016 UTC.  The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:48 <zodbot> The meeting name has been set to 'f25-final-go/no-go-meeting'
17:00:58 <jkurik> #meetingtopic F25 Final Go/No-Go meeting #2
17:01:07 <jkurik> #topic Roll Call
17:01:10 <sgallagh> .hello sgallagh
17:01:13 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:14 <fale> .hello fale
17:01:14 <jkurik> .hello jkurik
17:01:16 <zodbot> fale: fale 'Fabio Alessandro Locati' <fale@redhat.com>
17:01:19 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
17:01:51 * satellit listening
17:02:02 <jkurik> adamw, nirik, mboddu, dgilmore: are you around for the Go/No-Go meeting ?
17:02:28 <dgilmore> hols
17:02:32 <dgilmore> hola
17:03:28 <jkurik> ok, so we have a representant of FESCo and RelEng. We need someone from QE ....
17:04:51 <Kohane> Hi!
17:04:52 <dgilmore> adamw: tflink: around?
17:04:57 <Kohane> .fas lailah
17:04:58 <zodbot> Kohane: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
17:05:03 <nirik> morning
17:05:08 <mattdm> hi all
17:05:36 <jkurik> Hi everybody. Lets start with formalities and hopefully adamw will appear
17:06:04 <jkurik> #chair dgilmore mattdm sgallagh adamw
17:06:04 <zodbot> Current chairs: adamw dgilmore jkurik mattdm sgallagh
17:06:21 <jkurik> #topic Purpose of this meeting
17:06:22 <jkurik> #info Purpose of this meeting is to check whether or not F25 Final is ready for shipment, according to the release criteria.
17:06:41 <jkurik> #info This is determined in a few ways:
17:06:43 <jkurik> #info No remaining blocker bugs
17:06:44 <jkurik> #info Test matrices are fully completed
17:06:46 <jkurik> #info Final RC compose is available
17:06:59 <jkurik> #topic Current status
17:07:01 <jkurik> #info The F25 Final RC is available:
17:07:02 <jkurik> #link https://pagure.io/releng/issue/135
17:07:04 <jkurik> #link  http://dl.fedoraproject.org/pub/alt/stage/25_RC-1.3/
17:07:07 <jkurik> #info Test results for F25 Final are available:
17:07:22 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Summary
17:07:24 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Installation
17:07:25 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Base
17:07:27 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Server
17:07:28 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Cloud
17:07:30 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Desktop
17:07:31 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Security_Lab
17:07:32 <bowlofeggs> .hello bowlofeggs
17:07:33 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
17:07:54 <jkurik> There are still some blockers
17:07:56 <jkurik> #info We have 3 accepted blockers and 1 proposed blockers
17:07:57 <jkurik> #link https://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist
17:08:56 <sgallagh> Time for mini-blocker-review?
17:09:01 <jkurik> adamw: now we really need you :)
17:09:52 <jkurik> I can chair the mini blocker review, however without someone from QE we will not be able to make decisions I am afraid
17:10:28 <sgallagh> jkurik: Does the process actually state that? I thought it was just "consensus of the persons present"
17:10:33 <jkurik> There is a bankholiday day in CZ/Brno so even QE team from Brno is not available
17:11:23 <sgallagh> /me would like to believe that the set of people attending the Go/No-Go meeting would provide a reasonable cross-section of views.
17:12:17 <nirik> adamw was around a bit ago...
17:12:25 <jkurik> sgallagh: I am not sure. Reading https://fedoraproject.org/wiki/Go_No_Go_Meeting gives me no explicit answer to this
17:12:32 <adamw> .hello adamwill
17:12:33 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:12:46 <adamw> why do I never know when this meeting is
17:12:55 <jkurik> wow, we are ready to go now :)
17:13:07 <jkurik> thanks adamw for comming
17:13:14 <sgallagh> jkurik: My reading of that is that if there are unresolved blockers, the QA team's vote is automatically "block"
17:13:30 <jkurik> adamw: may I ask you please to lead the mini-blocker review ?
17:14:28 <adamw> 'meeting outcomes' states " Release is unanimously declared GOLD by a representative from Development, Release Engineering, and Quality Assurance."
17:14:44 <adamw> (though it doesn't actually seem to allow for any *other* outcome, which makes me wonder what we're doing here at all :>)
17:14:48 <adamw> sure
17:14:52 <jkurik> #topic Mini-Blocker Review
17:14:52 <adamw> did you chair me?
17:14:56 <sgallagh> /me opens the champaign
17:14:57 <jkurik> yes, I did
17:14:59 <adamw> roger
17:15:07 <sgallagh> err, champagne. Wow, spelling fail.
17:15:33 <jkurik> champagne spelling: whiskey ?
17:15:40 <adamw> hehe
17:15:51 <adamw> so we have one proposed blocker to review and one accepted that got re-opened to re-consider
17:15:51 <Kohane> LOL
17:16:02 <adamw> here's the proposed blocker:
17:16:03 <adamw> #topic (1394937) Running processes killed (SIGKILL) without a chance to shut down cleanly (SIGTERM) on logout or shutdown
17:16:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1394937
17:16:03 <adamw> #info Proposed Blocker, systemd, NEW
17:16:21 <adamw> so, I filed this, but there's still quite a bit of confusion due to insufficient investigation, i apologize for that
17:17:00 <nirik> based on what I know: -1 blocked +1 FE, we can (and should) fix in an update...
17:17:11 <sgallagh> I'm really on the fence with this one, because on the one hand, there's a slight chance of data loss, but on the other hand, this has been the behavior throughout the whole cycle and no one *noticed* any data loss.
17:17:11 <nirik> s/blocked/blocker/ sheesh
17:17:20 <sgallagh> And it's something that *can* be fixed post-release.
17:17:22 <adamw> it's difficult to really pin down any clear-cut case here aside from http://bugzilla.redhat.com/show_bug.cgi?id=1366897 , which we already discussed and rejected
17:17:27 <jkurik> yes, -1 to block and +1 to FE (perhaps 0day ?)
17:17:42 <adamw> i'm somewhat concerned by Bojan's case, but it doesn't seem clear enough to block on that alone.
17:18:04 <Kohane> I saw this behaviour long ago and I don't remember losing any data.
17:18:19 <Kohane> It was just annoying but not harmful. In my laptop at least.
17:18:24 <sgallagh> Kohane: Well, data-loss would be sort of a race-condition.
17:18:47 <sgallagh> It's possible that a process that is in the middle of writing data out to disk could be interrupted in the middle by the logout.
17:18:49 <adamw> jkurik: since we don't precisely even know what's broken yet, a 0-day fix seems unlikely :)
17:18:55 <sgallagh> But that's likely to be rare, since logout is a human action.
17:18:57 <nirik> it sounds like it also happens in f23/f24... or perhaps just f24 too...
17:19:04 <adamw> we do have the https://bugzilla.redhat.com/show_bug.cgi?id=1366897 case that's fairly clear, it would be nice if someone could sit on the desktop team for that one.
17:19:04 <jkurik> it was probably caused by an update (as it is present in F23 and F24 as well), so it can be fixed by an update as well
17:19:06 <sgallagh> (Meaning, you probably don't log out while you still have tasks running)
17:19:34 <Kohane> It doesn't happen to me in Workstation F24
17:19:34 <fale> -1 block +1 FE since we have it already in current release
17:19:59 <Kohane> jkurik: agree
17:20:14 <nirik> Kohane: gnome desktop? wayland or no?
17:20:25 <adamw> proposed #agreed 1394937 - it's still not entirely clear what (if anything) is broken here besides #1366897, which we already discussed and rejected as a blocker. we do not see anything else clear enough to constitute a blocker here
17:20:26 <Kohane> Gnome desktop, not Wayland
17:20:34 <Kohane> Maybe is it related to Wayland?
17:20:40 <jkurik> ack
17:20:41 <adamw> Kohane: the GNOME case is, we know that.
17:20:49 <nirik> ack
17:20:53 <adamw> the question is whether there's anything else going on here, which doesn't seem to be at all clear
17:22:11 <adamw> ack/nack/patch?
17:22:25 <sgallagh> considering
17:22:37 <sgallagh> ack
17:22:47 <Kohane> ack
17:22:57 <fale> ack
17:23:25 <mattdm> stickster: you representin' the desktop team here? See adam's comment above re https://bugzilla.redhat.com/show_bug.cgi?id=1366897
17:23:47 <nirik> he did vote in bug...
17:24:11 <adamw> i think that was more the 'sit on them' comment.
17:24:20 <adamw> #agreed 1394937 - it's still not entirely clear what (if anything) is broken here besides #1366897, which we already discussed and rejected as a blocker. we do not see anything else clear enough to constitute a blocker here
17:24:22 <nirik> ah, ok.
17:24:31 <adamw> okay, so, moving onto the accepted blocker that was re-opened
17:24:42 <adamw> #topic (1390607) LibreOffice Impress (and stripped down native gtk demo) doesn't run presentation correctly on Wayland
17:24:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1390607
17:24:43 <adamw> #info Accepted Blocker, mutter, ASSIGNED
17:27:03 <jkurik> I agree with stickster https://bugzilla.redhat.com/show_bug.cgi?id=1390607#c38 . -1 to block on this, +1 FE
17:27:46 <sgallagh> I think there's more going on here than just presentation mode, because on reading this more carefully, I've seen similar stuff happening with just regular windows being auto-placed in locations where it's impossible to reach their title bars.
17:27:47 <nirik> yeah, so it sounds like the base issue was fixed, but there is another corner case that can cause it to fail.
17:28:41 <fale> since it's possible to deliver a presentation (with mirroring) I'm for -1 block, +1 FE
17:28:49 <adamw> i think at this point we can probably document sufficient workarounds for the 'running a presentation from the live image' case, and fix it better with an update
17:28:58 <adamw> so i think i'm -1 now
17:29:01 <sgallagh> Yeah, I'm -1 to blocking at this point, since there are reasonable workarounds.
17:29:07 <nirik> yeah, -1 blocker
17:29:14 <Kohane> -1 blocker
17:29:18 <sgallagh> (By "reasonable" I mean, "most people could figure out to switch to mirroring")
17:30:46 <adamw> proposed #agreed 1390607 - RejectedBlocker - while it's unfortunate that this isn't fully fixed, we think the current state is good enough for release (we can document workarounds for the remaining broken cases), and we can fix it fully with an update
17:30:55 <nirik> ack
17:30:57 <fale> ack
17:31:00 <jkurik> ack
17:31:14 <sgallagh> ack
17:31:37 <Kohane> ack
17:32:39 <adamw> #agreed 1390607 - RejectedBlocker - while it's unfortunate that this isn't fully fixed, we think the current state is good enough for release (we can document workarounds for the remaining broken cases), and we can fix it fully with an update
17:33:29 <jkurik> adamw: I guess that is all, right ?
17:33:57 <sgallagh> The remaining two blockers are VERIFIED and were present in RC 1.3, as I understand it.
17:34:10 <jkurik> yes, I think so
17:34:49 <adamw> yep, that should be it
17:34:51 <jkurik> adamw++
17:34:53 <jkurik> thanks
17:34:56 <sgallagh> adamw++
17:34:56 <zodbot> sgallagh: Karma for adamwill changed to 18 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:35:05 <jkurik> #topic Test Matrices coverage
17:35:06 <Kohane> adamw++
17:35:07 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Summary
17:35:16 <sgallagh> ...huh, how did we get that far without my having given you a cookie yet?
17:35:38 <nirik> adamw++
17:36:19 <mattdm> adamw++
17:36:24 <adamw> aww, stoppit
17:36:38 <adamw> #info remaining accepted blockers have been verified fixed in RC-1.3
17:37:27 <jkurik> how you people see the test cases coverage ?
17:37:34 <Kohane> adamw: why stop? don't you like cookies?
17:38:48 <pbrobinson> Kohane: he's just being coy
17:39:27 <jkurik> is QA:Testcase_install_to_iSCSI_no_authentication mandatory on ARM ?
17:41:06 <pbrobinson> jkurik: not mandatory, it's there
17:41:41 <jkurik> than we have very strong coverage
17:41:51 <jkurik> is there anything I have overlooked ?
17:42:04 <adamw> good ol' SAS
17:42:11 <adamw> oh, unless tflink did it
17:42:28 <adamw> the guy who has the actual SAS device and hit an actual bug with it didn't report back yet whether the fix we put in RC-1.3 is sufficient or there's another bug behind it
17:42:29 <adamw> but, meh.
17:42:34 <tflink> nope, i can start a new run, though
17:42:53 * adamw stuffs tflink into the kparal isolation device
17:42:55 <adamw> nope. we're good.
17:43:04 <adamw> :P
17:43:05 <tflink> ok, either way
17:43:16 <adamw> nah, seriously, go ahead if you like. yours worked with RC-1.2 though, right?
17:43:20 <adamw> or 1.1 or whatever you tested
17:45:28 <jkurik> adamw: do you see this as potentionaly blocking issue ? should we wait for the tflink's result ?
17:45:44 <tflink> yeah, 1.2 worked fine
17:45:55 <sgallagh> jkurik: SAS is on the list of things that we may deprioritize in F26 anyway. I'm fine with trusting the 1.2 results.
17:46:01 <jkurik> ok, so lets move on then
17:46:27 <jkurik> proposed #info Test Matrices coverage for the Final release is pretty strong and sufficient
17:47:08 <dgilmore> ack
17:47:16 <sgallagh> ack
17:47:19 <fale> ack
17:47:33 <jkurik> #info Test Matrices coverage for the Final release is pretty strong and sufficient
17:47:37 <jkurik> #topic Go/No-Go decision
17:47:54 <jkurik> QE, FESCo, RelEng -> we need +1
17:48:05 <sgallagh> +1 with my FESCo hat on
17:48:06 <jkurik> dgilmore, sgallagh, nirik, adamw ^^^
17:48:19 <nirik> +1 to go
17:48:32 <dgilmore> +1 to go
17:48:41 <jkurik> for the record: I am +1 to GO
17:49:45 * stickster gets back from shop and +1's to go!
17:49:48 <adamw> coverage is fine, no outstanding blockers, so QA votes go.
17:50:01 <mattdm> figurehead fpl vote +1!
17:50:06 <stickster> adamw++
17:50:10 <jkurik> #info The Fedora 25 Final compose 1.3 is considered as GOLD
17:50:10 <sgallagh> /me opens another bottle of champagne
17:50:12 <stickster> I missed the cookie party
17:50:14 * adamw patpats mattdm
17:50:16 * Kohane is not in QE/FESCo/RelEng but also +1 to go
17:50:18 <jkurik> #link http://dl.fedoraproject.org/pub/alt/stage/25_RC-1.3/
17:50:22 <sgallagh> stickster++
17:50:22 <zodbot> sgallagh: Karma for pfrields changed to 19 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:50:24 <adamw> aww, isn't he a cute lil' figurehead
17:50:36 <jkurik> #action jkurik to publish the Go/No-Go result
17:50:40 <dgilmore> adamw++
17:50:41 <stickster> adamw: He needs that, he's now the "oldest" FPL and thus frequent comforting is required
17:50:54 <sgallagh> Is that official at this point?
17:50:58 <dgilmore> stickster: I thought it was frequent bourbon
17:50:59 <stickster> sgallagh: yup
17:51:03 <sgallagh> mattdm++
17:51:03 <zodbot> sgallagh: Karma for mattdm changed to 8 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:51:04 <stickster> as of last week I think?
17:51:10 <adamw> dgilmore: what's the difference?
17:51:12 <stickster> A record I'm happy to see broken
17:51:20 <Kohane> dgilmore: bourbon, comforting is all the same
17:51:42 <jkurik> #topic Open floor
17:51:45 <stickster> frequent Southern Comfort
17:52:11 <jkurik> someone would discuss anything releated to purpose of this meeting ?
17:52:30 <sgallagh> Actually, one question that I just thought of.
17:52:44 <sgallagh> adamw: Did the upgrade from F23 question ever get sorted out?
17:53:35 <sgallagh> For context: there was an issue with GNOME Software distro-upgrades where it was unpredictable which version would be shown to a user if there were two possible upgrade targets.
17:53:43 <dgilmore> adamw: I am sure there is some
17:54:16 <adamw> sgallagh: no, it didn't.
17:54:37 <sgallagh> OK, that's a bit concerning.
17:54:52 <adamw> sgallagh: my suggested gameplan is we see what happens when the pkgdb collections json is updated and then claim strenuously that's precisely what we intended to happen. whatever it turns out to be.
17:54:57 * adamw has plausible justifications ready.
17:55:26 <sgallagh> Is that JSON fixed for the life of the distro?
17:55:32 <sgallagh> (Will it change when F26 arrives?)
17:55:36 <adamw> i don't think it is theoretically, but i think it is practically.
17:55:44 * stickster notes that until we jump up to say two-release upgrades work well, they don't
17:55:50 <adamw> dgilmore / puiterwijk / someone would probably know better.
17:56:03 <adamw> stickster: we've been testing two-release upgrades for the last couple of cycles.
17:56:03 <sgallagh> stickster: We've been saying that they do for a couple releases now
17:56:11 <stickster> really?
17:56:13 <adamw> 23->25 is reasonably well tested, for default package cases at least.
17:56:26 <sgallagh> /me tested several 22->24 upgrades as well
17:56:29 <stickster> I must have missed that -- I knew some testing was happening but not that we said "supported" (for whatever that means for us)
17:56:35 <adamw> stickster: https://openqa.fedoraproject.org/tests/48901
17:57:08 <stickster> Hmm, it's like this open source stuff is a moving target ;-P
17:57:10 <adamw> stickster: it's written into the release criteria since ~22. what we really need to clear up next is what we actually tell people to do in the instructions.
17:57:16 <sgallagh> stickster: Yeah, we consider that "official" at this point
17:57:18 <adamw> which i'm supposed to be starting a thread about.
17:58:02 <dgilmore> I did 18 to 25 I do not recomend it
17:58:12 <sgallagh> That was... bold
17:58:20 <adamw> dgilmore: wuss. i did 13->25 while i was updating the 'upgrading with dnf' instructions.
17:58:32 <stickster> lol
17:58:34 <adamw> real testers do it with /usr move and grub2 migration
17:58:42 <dgilmore> adamw: :P
17:58:50 <stickster> adamw: I've said many times you have real testers
17:58:55 <adamw> :P
17:59:11 * stickster wins this meeting, mic drops
17:59:32 <sgallagh> OK, but back on track: we should probably make a group decision about how to handle that JSON situation. I don't *love* adamw's answer, but I can live with it.
18:00:03 <adamw> sgallagh: if we really want to achieve a specific outcome, we can try and make koji (or whatever it is that produces that JSON) produce a specific order.
18:00:31 <sgallagh> Right, so there are three possible choices:
18:00:32 <sgallagh> 1) Take whatever we get at random and justify it ex post facto
18:00:42 <sgallagh> 2) Assert that we always want upgrades to be single-version
18:00:47 <stickster> adamw: I thought that depending on the encoding/decoding lib JSON ordering wasn't settable... wouldn't a change to g-s be a better option?
18:00:53 <sgallagh> 3) Assert that upgrades should always go to the most recent stable version
18:01:17 <adamw> stickster: yes, it is, but twiddling the json output is easier. you *can* achieve specifically ordered json, it's just a bit of work.
18:01:19 <stickster> (assuming that's required, I'm flying blind here)
18:01:59 <mattdm> stickster: I vote #3
18:02:10 <mattdm> I mean, sgallagh :)
18:02:13 <sgallagh> If we take either 2) or 3), those would end up being "special blockers" (or whatever we're calling them now)
18:02:19 <Kohane> Yes, I think
18:02:24 <Kohane> #3
18:02:27 <Kohane> is better
18:02:33 <mattdm> People who want to go to an intermediate version can use the command line
18:02:44 <jkurik> I am #3
18:02:51 * nirik nods. seems reasonable
18:03:07 <stickster> #3 seems reasonable to me too
18:03:19 <sgallagh> OK, but that's half the question. The other half is: are we willing to slip for #3 if we had to?
18:03:46 <sgallagh> /me doesn't know if kalev or hughsie would be able to fix this by Tuesday, if it needs GNOME Software changes.
18:03:54 <mattdm> sgallagh: NO
18:04:06 * stickster points out #3 is SHOULD, not MUST -- and would not want to see that be a blocking criterion (although "upgrades MUST work when they happen" seems reasonable)
18:04:09 <stickster> sgallagh: NO WAY
18:04:26 <mattdm> I already tweeted about it. This is a done deal.
18:04:28 <mattdm> :)
18:04:34 <nirik> heh.
18:04:36 <dgilmore> adamw: what json?
18:04:38 <sgallagh> stickster: You caught me. I used my least-favorite word in 2) and 3)
18:04:44 <sgallagh> I meant to say "must"
18:04:54 <nirik> the releases json on the pkgdb api
18:04:56 <adamw> dgilmore: https://admin.fedoraproject.org/pkgdb/api/collections/
18:04:56 <stickster> i.e. if we release F26 and the only remaining blocker is "F25 shows up as upgrade instead of F26 for F24," I wouldn't block on that.
18:05:20 <Kohane> Neither I.
18:05:27 <Kohane> It's not a blocker.
18:05:38 <dgilmore> adamw: pkgdb makes that inside of itself
18:05:48 <adamw> dgilmore: once F25 goes stable, gnome-software in F23 will offer upgrade to *either* F24 or F25, depending on whether F25 comes above or below F24 in that list after it's changed to 'Active' status
18:06:05 <adamw> whichever one comes last will be the one it offers
18:06:19 <dgilmore> adamw: if its in the wrong order, we will have to file a pkgdb bug to fix it
18:06:54 <adamw> (well, in a 'clean' case. i haven't actually looked into how aggressively it re-considers, if it's already noticed that F24 is available and you don't force it to refresh.)
18:07:45 <nirik> well, as long as the "right" order is known. ;)
18:08:32 <adamw> right, we don't actually know what we want yet.
18:08:56 <adamw> i'm not sure we want to just make a hasty decision in this meeting. i was planning a devel@ thread. as this is really about the package maintainers
18:09:02 <adamw> they're the ones who have to make sure the upgrade works
18:09:08 <sgallagh> I think it's pretty clear that the folks in this meeting want it to be 3) above
18:09:14 <sgallagh> (I agree, FWIW)
18:09:19 <stickster> adamw: sensible.
18:09:38 <adamw> in theory we're already requiring them to fix N+2 upgrade bugs, but still, it's worth a wider airing i think.
18:09:44 * stickster does think that fiddling JSON seems hackier than telling the software to "find the latest"
18:10:07 <stickster> ideally that would be something settable by policy, too
18:10:13 <stickster> "find next" vs. "find latest"
18:10:24 <adamw> stickster: haha, configuration options in GNOME, are u serious
18:10:35 <stickster> adamw: PackageKit.conf is a thing ;-)
18:10:51 <stickster> settable by distro policy I mean
18:11:13 <adamw> you want the KDE upgrader, which has settings for 'upgrade to next', 'upgrade to latest', 'upgrade to random', 'downgrade to last release preferred by people on reddit', and 'upgrade to arch'
18:11:24 <adamw> plus a button that no-one's sure what it does
18:11:28 <stickster> Yes, that is DEFINITELY what I want :-D
18:11:39 <sgallagh> adamw: Oh, they eliminated the other three nonce buttons?
18:11:42 <adamw> heh
18:12:12 <adamw> stickster: it's probably going to wind up being settable per distro just because of how this is actually implemented in g-s, but yeah, i agree.
18:12:42 * stickster notes diminshing returns at this point... maybe time to close this up with #action
18:12:56 <jkurik> I vote for a discussion in mailing list thread.
18:13:24 <adamw> yup
18:13:27 * adamw writes it
18:14:14 <sgallagh> OK, thanks
18:14:56 <jkurik> #action adamw to start discussion about GNOME Software distro-upgrades on @devel list
18:15:07 <jkurik> anything else for today ?
18:15:58 <jkurik> ok, than thanks folks for comming
18:16:10 <jkurik> #endmeeting