16:00:13 <kalev> #startmeeting FESCO (2016-06-03)
16:00:13 <zodbot> Meeting started Fri Jun  3 16:00:13 2016 UTC.  The chair is kalev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:13 <zodbot> The meeting name has been set to 'fesco_(2016-06-03)'
16:00:13 <kalev> #meetingname fesco
16:00:13 <kalev> #chair maxamillion dgilmore number80 jwb nirik paragan jsmith kalev sgallagh
16:00:13 <zodbot> The meeting name has been set to 'fesco'
16:00:13 <zodbot> Current chairs: dgilmore jsmith jwb kalev maxamillion nirik number80 paragan sgallagh
16:00:16 <kalev> #topic init process
16:00:23 <sgallagh> .hello sgallagh
16:00:24 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:00:25 <nirik> morning
16:00:28 <kalev> morning
16:00:28 <nirik> .hello kevin
16:00:31 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
16:00:32 <number80> .hello hguemar
16:00:33 <paragan> .hello pnemade
16:00:34 <zodbot> number80: hguemar 'Haïkel Guémar' <karlthered@gmail.com>
16:00:37 <zodbot> paragan: pnemade 'Parag Nemade' <pnemade@redhat.com>
16:01:17 <kalev> ok, so we have quite a few things on agenda for this week
16:01:40 <kalev> let's do the ones that are time critical first, the systemd thingie and graphical system upgrades
16:01:48 <jsmith> .hello jsmith
16:01:49 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
16:01:54 <sgallagh> kalev: Makes sense
16:01:59 <jsmith> WORKSFORME
16:02:00 <kalev> #topic #1576 Evaluate Workstation graphical upgrade Change status
16:02:00 <kalev> .fesco 1576
16:02:01 <zodbot> kalev: #1576 (Evaluate Workstation graphical upgrade Change status) – FESCo - https://fedorahosted.org/fesco/ticket/1576
16:02:01 <kalev> https://fedorahosted.org/fesco/ticket/1576
16:02:45 <kalev> I talked to hughsie and came up with a plan how to do this; it's in the ticket, #topic #1576 Evaluate Workstation graphical upgrade Change status
16:02:48 <kalev> .fesco 1576
16:02:50 <zodbot> kalev: #1576 (Evaluate Workstation graphical upgrade Change status) – FESCo - https://fedorahosted.org/fesco/ticket/1576
16:02:53 <maxamillion> .hello maxamillion
16:02:53 <sgallagh> kalev: Any chance of moving up the second round to Monday rather than Tuesday?
16:02:56 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:02:58 <maxamillion> sorry for being late
16:03:01 <kalev> err, copy paste failure
16:03:02 <kalev> https://fedorahosted.org/fesco/ticket/1576#comment:19
16:03:11 <kalev> sgallagh: I'm gone on Monday, it's a holiday here
16:03:23 <kalev> otherwise yeah
16:03:28 <sgallagh> It can take up to 48 hours to get to the mirrors, so it may not actually be tested by Go/No-Go
16:04:02 <nirik> that seems a bit pessimistic to me. ;)
16:04:42 <maxamillion> it's true though, yes?
16:04:57 <sgallagh> nirik: If you want real pessimism, I could have mentioned how nothing except web browsers and the kernel ever gets tested in u-t anyway :-P
16:05:01 <number80> kalev: how optimistic are you that can meet the deadline in your proposal?
16:05:03 <nirik> well, if there's some horrible problem that blocks all updates, sure, it could be
16:05:07 <number80> *you
16:05:22 <nirik> but thats pretty rare these days
16:05:36 <nirik> sgallagh: you don't have proof of that. ;)
16:05:55 <sgallagh> nirik: No one *ever* files a bug on any of my packages until they hit stable.
16:05:58 <kalev> number80: well, it's roughly working, but there are still some bugs left. I think we can fix a few more bugs by that time, definitely not everything though
16:06:04 <nirik> that does not mean they were not tested.
16:06:21 <sgallagh> nirik: On several occasions, it surely did
16:06:33 <kalev> I'd like the QA team's opinion at that point to see what they think, if it's good enough for the users or not
16:06:34 <nirik> kalev: so, those bugs would stop it going out ? or are they mostly minor?
16:06:43 <number80> kalev: well, if they are critical bugs (one that left users w/ unusable system) then -1, else we can discuss
16:07:11 <kalev> some are annoying, like it doesn't handle network errors gracefully and stops the download when a download gets interrupted
16:07:27 <nirik> sgallagh: sure, but in many cases people only complain when something breaks and they have time to complain... they are still testing it. Anyhow, this is off topic a bit
16:07:28 <kalev> I am not aware of anything that would leave users with unusable systems
16:07:28 <sgallagh> Let me ask a slightly stricter question: If we asked you to go stable *right now*, would you be afraid of leaving people broken?
16:07:59 <kalev> I don't think so
16:08:06 <jsmith> I've got to be honest -- I'm a little nervous about leaving this to the last minute
16:08:06 <number80> better
16:08:41 <number80> then, we have to get QA feedback on the proposal
16:08:45 <maxamillion> jsmith: +1
16:08:57 <nirik> qa feedback/more testing would be very nice.
16:09:04 <kalev> yep, agreed
16:09:04 <number80> adamw: ??
16:09:11 <adamw> kparal's been testing this quite a lot as it went along
16:09:32 <jsmith> nirik: I guess my next question is -- how likely is it that we'll get sufficient testing between now and crunch time?
16:10:07 <nirik> well, depends on what you mean by sufficent. ;) but yeah, kparal has been testing and closing/filing new bugs
16:10:13 <sgallagh> jsmith: Define "crunch time"? Because we're already in Freeze
16:10:28 <kalev> https://bugzilla.redhat.com/show_bug.cgi?id=1308538 has a list of bugs that kparal and co found, some are fixed, some not
16:10:39 <adamw> there are a couple of issues kparal filed this week which look quite significant:
16:10:39 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1341151
16:10:40 <jsmith> sgallagh: Dang it -- you totally stole my punch line :-p
16:10:45 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1341159
16:10:47 <kalev> those in the modified state are fixed
16:11:52 <jsmith> I'm more worried about the "upgrade silently fails" one, personally
16:12:22 <adamw> so, i guess i'd say QA team is somewhat worried that this is all being rushed quite a lot and there was no real plan for how to get it out, but i'm not sure we have a better idea than the proposal
16:12:40 <adamw> i guess it would be good for PR stuff to have a plan for both possible outcomes (graphical upgrade available/not available on release day)
16:12:54 <cmurf> the concern is always the unknown potential for edge cases that turn out to have broad impact (significant minority)
16:13:01 <nirik> both those seem to be error handling/network issues.
16:13:54 <sgallagh> Yeah, I don't *love* that the user isn't informed that the upgrade failed, but if this were a Go/No-Go decision, I wouldn't block on either of those.
16:14:11 <nirik> hopefully they can get fixed by tuesday?
16:14:13 <sgallagh> (since the net result is that the system remains in its pre-upgrade state)
16:15:47 <kalev> anyway, we'll have another meeting next Friday and we can take another look at this then to see how it's been progressing
16:15:52 <nirik> so, I'm +1 to the plan... but of course sooner better than later for the next round of fixes...
16:16:09 <adamw> kalev: 24 go/no-go is next thursday.
16:16:10 <nirik> well, next friday is after go/no-go...
16:16:14 <adamw> meetings next friday are a bit late. :P
16:16:43 <jsmith> Yeah, definitely too late :-(
16:17:59 <sgallagh> Unless of course the question on the table is whether FESCo should flex use its "FESCo Blocker" power and decide to slip a week right now.
16:18:09 <sgallagh> (For the record, I'd vote -1 to such a request)
16:18:12 <kalev> I personally am fine with either way, to have it in place by GA time and also fine with having it go out a week or two later
16:18:56 <cmurf> OK so usually the recommended/supported upgrade method is release blocking, so what I'm hearing is that the graphical upgrade tool might not be release blocking
16:19:17 <nirik> well, if we have time to work on/fix some more issues before go/no go that would be great. Do we think we do ?
16:19:18 <cmurf> if it's not ready then ship anyway but not enable this feature
16:19:25 <sgallagh> I *think* we decided weeks ago that this wasn't the official method for F24
16:19:43 <kalev> nirik: yep, I'm planning on working on this next week, should be able to fix several of the issues
16:19:44 <nirik> right, it doesn't need to be tied to the release, we could wait until after to announce/enable it
16:19:52 * kalev nods.
16:20:15 <cmurf> OK and how do the marketing and web folks feel about a last minute decision on this feature?
16:20:25 <kalev> in my proposal, I only tied it to go/no-go just to be able to give a heads up to the marketing team
16:20:38 <kalev> I didn't mean that it should block the release from going out
16:20:38 <sgallagh> Honestly, I'm of a mind that we should just tell marketing/docs folks to continue directing people to the `dnf system-upgrade` approach as the official answer.
16:20:44 <nirik> they seemed ok with it as far as I know. There's a magazine article on it, but it's waiting until the go ahead to publish.
16:21:07 <nirik> and mattdm wanted to know what to use in the release announcement.
16:21:43 <nirik> so I am ok waiting until tuesday to decide if we want it at release or want to wait.
16:21:53 <nirik> but we should make sure and have that conversation then
16:22:22 <maxamillion> nirik: +1
16:22:23 <kalev> oh, tuesday, not thursday?
16:22:42 <sgallagh> kalev: We need lead time for the marketing folks.
16:22:59 <kalev> fair enough
16:23:03 <nirik> kalev: well, thursday seems late to set the wheels in motion...
16:23:07 <nirik> and get the update stable and such
16:23:08 <sgallagh> At Go/No-Go (and Readiness) it's final sign-off
16:24:22 <nirik> would QA folks be ok with that? or prefer to just slip it out a week or two?
16:24:49 <maxamillion> it might almost be better just to slip a week or two if this is something we're gunnign for
16:25:09 <maxamillion> seems like a really narrow window
16:25:22 <paragan> Is this really that much important to slip a release?
16:25:33 * jsmith is against slipping the release for this, for the record
16:25:37 * nirik also
16:25:39 * kalev too
16:25:42 * paragan too
16:25:47 <sgallagh> I think they meant not slipping Fedora but the release of this feature
16:25:55 <sgallagh> Since it's not *strictly* tied to the Fedora release.
16:26:01 <sgallagh> Because it's an update to the older Fedora
16:26:04 <cmurf> And the availablity of graphical upgrades depends on the system receiving an update that changes gnome-software's fedora.json file such that the status key flips from Under Development value to Active value?
16:26:18 <nirik> It's better if it goes out with release (more buzz, etc), but if it goes out a week or two later... it's still there.
16:26:33 <kalev> cmurf: no; that's downloaded from pkgdb. pkgdb flips the value once F24 is officially out
16:26:34 <cmurf> So that flip might happen a week after GA for many systems?
16:26:55 <cmurf> OK but it requires a download? So there's a delay?
16:27:23 <cmurf> And actually the delay is non-deterministic so it's no like everyone gets flipped over at the same time?
16:27:56 <kalev> I mean, once the new gnome-software that supports sytem upgrades goes reaches users systems, it goes and downloads the status file from pkgdb
16:28:09 <kalev> so everybody should get it about the same time
16:28:19 <sgallagh> cmurf: The availability of the upgrade in this specific instance is dependent on when the mirrors get the gnome-software release that supports it.
16:28:33 <cmurf> Alright so it kinda needs to work well and hopefully have few edge cases that are really bad.
16:28:41 <sgallagh> In future updates, it will be simultaneous because F24+ will already have this feature.
16:28:45 <cmurf> And that's just difficult witout a lot of testing.
16:28:51 <kalev> right
16:29:12 <cmurf> Really this is a trust issue due to lack of volume testing. No way around that really.
16:30:01 <sgallagh> Right, the only ways to get real volume testing would be a) an enormous beta testing program or b) turn it on and pray.
16:30:13 <cmurf> Ok so we're going with b. Fine.
16:30:45 <kalev> I wonder if we could approach it more systematically
16:31:17 <kalev> adamw: do you think you and kparal could come up with a list of bugs that we should fix before putting it to stable in F23?
16:31:20 <cmurf> If there were a way to scale out the pkgdb switch flipping so it's not happening all at once...
16:31:34 <kalev> adamw: like, blockers for this to go to stable?
16:31:40 <adamw> kalev: probably primarily kparal, but sure.
16:31:48 <kalev> and then we can just look at the bugs and see if they are fixed and it is an easy decision then
16:31:58 * nirik nods. seems reasonable.
16:32:09 <sgallagh> cmurf: Well, in reality it's not like everyone is going to hit the upgrade button at the same time either
16:32:12 <sgallagh> This is opt-in.
16:32:32 <nirik> or everyone is going to update to the gnome-software+friends packages that offer it at the same time
16:32:32 <adamw> i guess this is where we wish we had some sort of staged roll-out thing like the big dogs, but we don't. :P
16:32:42 <sgallagh> I imagine plenty of people will play wait-and-see whether others have problems with it
16:32:48 <cmurf> Sure I mean if there's a fire, a nice way to not have to notify people "don't click the button" would be neat.
16:32:58 <jsmith> Between it being opt-in and not everyone downloading updated packages at the same time, I don't think it's a huge issue
16:33:11 <sgallagh> cmurf: We could always unflip the pkgdb settnig
16:33:19 <sgallagh> Flip it back to prerelease manually
16:33:26 * jsmith blinks...
16:33:28 <sgallagh> (I'm spitballing here)
16:33:39 <jsmith> sgallagh: OK, just checking :-)
16:33:40 * kalev nods.
16:33:43 <cmurf> Yeah but if most everyone gets the switch flipped at about the same time, kinda pointless.
16:33:53 <cmurf> That's why I'm spitballing how to scale out such changes.
16:33:53 <sgallagh> cmurf: Again, it doesn't cause an automatic upgrade
16:34:00 <sgallagh> It requires a conscious decision to move
16:34:09 <sgallagh> So not everyone is going to do that right away
16:34:14 <cmurf> I know, but there's also no automatic "don't click it we found a big bug!" notification.
16:34:17 <nirik> anyhow, it's been more than 30min now. ;) Should we just agree to look tuesday/wed morning and if all stable blockers are fixed we go with the release, otherwise we iterate another week?
16:34:23 <adamw> sgallagh: please don't make pkgdb lie, fedfind relies on it.
16:34:40 <adamw> it would then decide that 24 wasn't the current release any more and various things would go squiffy.
16:34:50 <kalev> nirik: yep, let's do that, sounds like a good plan to me
16:34:52 <adamw> (squiffy is a highly technical term)
16:34:54 <sgallagh> adamw: That's almost worth it for the humor value alone!
16:35:17 <nirik> "We are bringing back Classic F22" :)
16:35:22 <cmurf> squiffy sounds British
16:35:25 <gholms> Heh
16:35:49 <kalev> #action adamw and kparal to determine a list of blockers bugs for the graphical system upgrade feature
16:36:03 <kalev> and then we'll see next week
16:36:09 <kalev> ok, let's move on
16:36:31 <kalev> #topic #1580 Systemd changes - Request - KillUserProcess behavior change
16:36:31 <kalev> .fesco 1580
16:36:31 <kalev> https://fedorahosted.org/fesco/ticket/1580
16:36:33 <zodbot> kalev: #1580 (Systemd changes - Request - KillUserProcess behavior change) – FESCo - https://fedorahosted.org/fesco/ticket/1580
16:36:50 <kalev> zbyszek: you are up!
16:36:52 <sgallagh> /me put a proposal in the ticket and zbyszek didn't seem opposed to it.
16:37:08 <sgallagh> zbyszek: Sorry we didn't have you CCed there earlier. I missed that
16:37:15 * nirik is ok with sgallagh's proposal. I am not sure it's that big a deal to leave on in rawhide in the mean time, but sure.
16:37:57 <kalev> I'm ok with sgallagh's proposal too
16:38:04 <paragan> yes +1 to sgallagh proposal in ticket
16:38:13 <nirik> one side note: I actually didn't have it enabled here on my rawhide laptop... because long ago I edited logind.conf to change HandleLidSwitch which I think many laptop users may have done...
16:38:27 <zbyszek> I would prefer to leave this in rawhide as is. If you don't like the default, it's easy enough to change, and I want to get some testing.
16:38:52 <zbyszek> After all, Rawhide *is* for testing new things.
16:38:52 <nirik> oh, actually I do have it enabled. I am not sure it's working as expected fully tho
16:38:59 <maxamillion> I'm +1 to sgallagh proposal in the ticket also, I voiced that in ticket as well
16:39:40 <adamw> zbyszek: well, rawhide is for working towards future Fedora, not for throwing any old stuff you want to try out at. if fedora is sure we don't want the upstream default it's not appropriate to leave it in rawhide for a while just to give upstream some data.
16:39:57 <nirik> zbyszek: should I file those enhancements I suggested on list upstream? (logging whats killed and a permissive mode)
16:40:33 <zbyszek> nirik: No, I don't think so. It's on my agenda anyway.
16:40:44 <sgallagh> adamw: To be fair, we don't yet know if Fedora wants it or not. That's largely because we didn't have any time to think about it before it hit and people started complaining
16:40:49 <nirik> zbyszek: ok, just checking. If you want to look at them thats great.
16:41:17 <kalev> so, I think it's also a bit of a social issue here
16:41:18 <zbyszek> adamw: I would presume that FESCo would accept the Change, when it's proposed. So I don't see much value in flipping it back and forth.
16:41:30 <jkurik> zbyszek: are you going to propose a Change for F25 ?
16:41:34 <sgallagh> zbyszek: That's not necessarily a safe assumption.
16:41:45 <adamw> zbyszek: that seem presumptuous.
16:41:47 <kalev> I haven't read through all of the thread of doom on the devel list, but I think many people are opposed to that right now because they were unsure how it affects their favourite apps
16:41:48 <sgallagh> /me notes that Debian resolved not to accept that change in their downstream
16:41:49 <adamw> but anyhoo
16:41:53 <nirik> kalev: I think it's _mostly_ a social issue. ;)
16:42:11 <jwb> nirik: i don't
16:42:14 <kalev> and if we approach it in the way where we back down for a little bit, and then come up with a plan how to keep things working
16:42:20 <maxamillion> I'm with jwb on this one
16:42:22 <kalev> they'd be more open to the change
16:42:47 <zbyszek> Well, if FESCo decides to reject the change, then there should be plenty of time to change it back.
16:42:51 <sgallagh> I think that the problem is that both "sides" of this argument are acting from an incomplete set of expectations.
16:43:19 <sgallagh> Lennart's point is valid: my expectation when I log out of all sessions is that anything I started exits.
16:43:22 <kalev> I definitely don't want to reject this change, but just approach it with a plan instead of just putting it in rawhide
16:43:37 <sgallagh> *Except* certain tasks that I have different expectations for, like screen.
16:43:44 <maxamillion> I think there needs to be time for various projects that rely on the old functionality to have solutions to cope with the new functionality before we can realistically make it the default, otherwise we're just breaking everyone's user experience
16:43:52 <nirik> well, the social problem is that it's poorly announced and pushed out on one side, but also full of torches and pitchforks on the other side.
16:43:52 <jsmith> maxamillion: +1
16:44:06 <jsmith> nirik: I agree...
16:44:08 <sgallagh> Which I use regularly to protect against network hiccups when doing long-running things that might not handle disruption well
16:44:22 <sgallagh> maxamillion: I would certainly agree with that
16:44:43 <sgallagh> And ultimately it's FESCo's job to decide *when* that point has been reached.
16:44:45 <cmurf> I have not tested this but e.g. what of a gnome user in terminal doing "sudo btrfs scrub" that's expected to take take two days and then they logout? That should keep running. Things *like* that, not that specifically. But the scope of what's affected is unclear.
16:45:11 <nirik> Also, there's a lot of confusion around how it works... in my testing here it didn't work as I was expecting or told on the mailing list. This might be due to bugs, but it's definitely due to not enough docs
16:45:13 <jwb> cmurf: unless they put it in the background, it won't even stay running before this change
16:45:14 <mclasen___> why should it stay running ?
16:45:19 <rdieter> I don't get the uproar, reverting to prior behavior is editing a single line in a single conf file, isn't it?  (as long as that's clearly documented...)
16:45:48 <sgallagh> rdieter: By the same logic, switching it on to test it is a single edit.
16:46:08 <sgallagh> But the problem is that switching the default without discussion or consideration of broken workflows is a problem
16:46:08 <rdieter> sgallagh: ok, to *me* this is for power users, not average joe
16:46:10 <jwb> rdieter: because it was unannounced at fundamentally changes how lots of people use their computers.  people are angry because things that have been working for years suddenly don't work and they have to go figure out why
16:46:18 <maxamillion> I'm for one a fan of the change, the ideas behind it and where systemd is trying to go by making the change, but I think there needs to be a bit more of a "transition" phase before it's the default in the distro
16:46:30 <adamw> rdieter: changing most things is easy *once you know what it is that you need to change*. if your experience is just 'hey, screen suddenly isn't working the way it has for the last 20 years', you don't magically know which line of which file to change.
16:46:40 <nirik> jwb: well, they think that will happen... I doubt very much it has to those people yet.
16:46:42 <gholms> rdieter: Without foreknowledge of the change it is not clear what kills people's processes.  That's why nirik's logging suggestion would be useful.
16:46:52 <rdieter> adamw: that's why I emphasised "as long as it's clearly documented"
16:46:52 <sgallagh> maxamillion: I'm in the same boat: I think it's a good idea poorly executed so far.
16:46:54 <maxamillion> sgallagh: +1
16:47:01 <adamw> rdieter: fair enough, wasn't quite sure what you meant by that.
16:47:11 <jwb> rdieter: documentation is not a solution
16:47:18 <rdieter> jwb: for powerusers it is
16:47:24 <rdieter> imho
16:47:26 <jwb> i disagree
16:47:45 <nirik> in any case, given the controversy and need for changes to apps and docs, I think it's best to default it to off for now, until/unless the change is accepted.
16:47:49 <jwb> "poweruser" is a term people use when they want to say "that behavior is niche"
16:47:50 <sgallagh> rdieter: Power users tend to be the ones with the largest collections of macguyvered scripts and tools that will be broken by this
16:48:04 <rdieter> shrug, again, I still don't get it
16:48:15 <sgallagh> nirik: +1
16:48:18 <kalev> so, I think sgallagh's proposal makes sense here: flip the default in rawhide to what it was before, come up with a Change page that explains how various projects should cope with it (GNOME, KDE, screen, etc), and how to test it
16:48:27 <kalev> and then turn it on when we have a good plan there
16:48:56 <sgallagh> kalev: To be fair, my proposal *suggested* the latter, but did not mandate it.
16:49:01 <kalev> right
16:49:09 <nirik> If upstream can add permissive logging feature we could enable that and see the scope of affected things better
16:49:19 <kalev> zbyszek: would you be fine with this?
16:49:24 <sgallagh> (I don't want us nitpicking that point right now; the proposal at the moment is just "Turn it back and require a Change Proposal for future discussion:
16:49:28 * mclasen___ points out that there is actual breakage from switching it back
16:49:38 <nirik> mclasen___: oh?
16:49:39 <kalev> mclasen___: oh, what breakage?
16:49:40 <maxamillion> mclasen___: what?
16:49:43 <jsmith> mclasen___: Can you elaborate?
16:49:45 <mclasen___> stuff leaks out of the session
16:49:49 <mclasen___> thats why the change was made
16:49:53 <nirik> mclasen___: note, it's only on in rawhide.
16:49:57 <sgallagh> mclasen___: I discussed this with halfline yesterday
16:50:06 <sgallagh> The result is that the behavior is the same as in F24 today.
16:50:12 <mclasen___> you are a bit cavalier about 'this is just broken desktop stuff'
16:50:12 <maxamillion> mclasen___: is that a net new breakage or just a continuation of breakage that's been around forever?
16:50:13 <nirik> yes, there was a bug, but he seemed to think it was not serious enought to enable it.
16:50:22 <nirik> well, to slip
16:50:24 <rdieter> maxamillion: continuation
16:50:27 <sgallagh> And he and I decided that while it was unfortunate, it certainly wasn't blocker-worthy
16:50:28 <zbyszek> I can volunteer to submit a change page, and "fix" screen. But I'm not volunteering to handle GNOME, KDE, and an open-ended list of other projects.
16:50:41 <mclasen___> its been around forever, but it is much more pronounced since user bus was introduced last august
16:50:47 <sgallagh> maxamillion: It's new as of F24 because of the way that D-BUS switched from a session bus to a user bus
16:50:54 <maxamillion> ah
16:50:58 * nirik doesn't think it's just gnome, or just desktops...
16:51:10 <mclasen___> if anything *that* is the sneaked in change tat wasn't sufficiently discussed
16:51:20 <maxamillion> fun
16:51:27 <jsmith> nirik: +1 to asking for the logging functionality, FWIW
16:51:55 <jsmith> mclasen___: I agree :-)
16:51:56 <sgallagh> mclasen___: Maybe so, but given that few people have even noticed that it happened, I'd say it wasn't as earth-shattering a change.
16:52:02 <nirik> zbyszek: any chance also you could get tmux people to accept something? I know you tried... but perhaps a patch could be acceptable to them?
16:52:06 <sgallagh> But I agree it should have come in as a Change Proposal too
16:52:20 <spstarr> if I may ask, why don't we fix the fundamental problem in the first place? the systemd feature *is* good, im not saying it's not, but let's properly fix software vs adding an option to break 'the status quo'
16:52:39 <sgallagh> spstarr: Let's take that to #fedora-devel
16:52:43 <sgallagh> It's off-topic
16:52:48 <zbyszek> nirik: I don't want to promise to work on something that is likely to be rejected.
16:53:16 <nirik> zbyszek: fair. I just had hopes as I use tmux a lot. Perhaps we can find someone who upstream trusts more to submit something
16:53:16 <sgallagh> zbyszek: Would a statement from FESCo that we would carry that patch downstream be acceptable?
16:53:29 <sgallagh> (if upstream rejected it)
16:53:38 <nirik> well, it wasn't clear what they would accept...
16:53:55 <kalev> yes, definitely, we can patch things downstream if needed
16:54:00 <nirik> and the issue got spammed and the people with pitchforks and torches showed up and they closed it.
16:54:37 <cmurf> Well it ended up on Twitter so... pitchforks and torches go along with that.
16:54:41 <nirik> yep
16:55:09 <zbyszek> sgallagh: sorry, I cannot really answer, I haven't looked at tmux code, I have no idea how much work that would be.
16:55:31 <nirik> we can try and sort it, we are drifting off topic. ;)
16:56:05 <kalev> anyway, I think mostly everybody seems fine with sgallagh's propsal
16:56:16 <maxamillion> so basically, change proposal for f25, patches for screen and tmux would be nice and/or some kind of migration plan ... anything else?
16:56:18 <sgallagh> kalev: Probably best to get an actual count, though
16:56:28 <kalev> zbyszek: you are fine with filing a Change page, right? you definitely don't need to fix everything yourself, just highlight things that _someone_ has to fix
16:56:33 <zbyszek> Yes.
16:56:35 <kalev> good.
16:56:46 <jsmith> +1 to sgallagh's proposal from me
16:56:49 <kalev> ok, let's vote on sgallagh's proposal; sgallagh can you write it here once more for posterity?
16:57:06 <nirik> thanks zbyszek for all your work on this and answering peoples dumb questions. :) It's appreciated.
16:57:06 <maxamillion> + to sgallagh's proposal
16:57:10 <maxamillion> +1 to sgallagh's proposal
16:57:12 * maxamillion can't type
16:57:23 <sgallagh> +1 (for the record)
16:57:33 <kalev> +1
16:57:43 <jwb> +1
16:57:47 <paragan> +1
16:58:01 <sgallagh> zbyszek: Yes, please understand that we're appreciative, but we also need to balance expectations. And it's a polarizing issue.
16:58:10 <nirik> +1
16:58:36 <kalev> ok, that's +6
16:59:22 <maxamillion> sgallagh: +1
17:00:05 <jsmith> +1 (again)
17:00:23 <zbyszek> nirik, sgallagh: thanks.
17:00:48 <kalev> #agreed Revert KillUserProcess change in rawhide; zbyszek to come up with a Change proposal for this (+1:7, 0:0, -1:0)
17:01:10 <kalev> ok, moving on
17:01:11 <kalev> #topic #1578 F25 System Wide Change: Use /etc/repos.d as default reposdir
17:01:14 <kalev> .fesco 1578
17:01:15 <zodbot> kalev: #1578 (F25 System Wide Change: Use /etc/repos.d as default reposdir) – FESCo - https://fedorahosted.org/fesco/ticket/1578
17:01:17 <kalev> https://fedorahosted.org/fesco/ticket/1578
17:01:45 <jkurik> this one has been canceled by the Change owner
17:01:53 <kalev> jkurik wanted us to note that this has been cancelled
17:01:57 <jkurik> I just left it open for awareness
17:01:58 <kalev> noted, thanks!
17:02:12 <kalev> #topic #1581 Unresponsive maintainer: asaf
17:02:12 <kalev> .fesco 1581
17:02:13 <kalev> https://fedorahosted.org/fesco/ticket/1581
17:02:13 <zodbot> kalev: #1581 (Unresponsive maintainer: asaf) – FESCo - https://fedorahosted.org/fesco/ticket/1581
17:02:56 <kalev> looks like they've left years ago, I guess it makes sense to orphan all of asaf's packages?
17:03:19 <kalev> Proposal: orphan all of asaf's packages
17:03:21 <kalev> +1
17:03:26 <nirik> there's only 2. ;) but yeah, +1
17:03:30 <jsmith> +1 from me (sadly)
17:03:32 <sgallagh> +1
17:03:42 <maxamillion> +1
17:03:49 <paragan> +1
17:04:01 <jwb> +1
17:04:05 <kalev> #agreed orphan all of asaf's packages (+1:7, 0:0, -1:0)
17:04:14 <kalev> nirik: will you do that?
17:04:28 <nirik> sure. can do
17:04:34 <kalev> perfect, thanks
17:04:36 <kalev> nirik++
17:04:44 <kalev> #topic #1582 Reassign nodejs packages owned by 'patches' to
17:04:44 <kalev> group::nodejs-sig
17:04:44 <kalev> .fesco 1582
17:04:45 <kalev> https://fedorahosted.org/fesco/ticket/1582
17:04:45 <zodbot> kalev: #1582 (Reassign nodejs packages owned by 'patches' to group::nodejs-sig) – FESCo - https://fedorahosted.org/fesco/ticket/1582
17:05:00 <sgallagh> +1 from me (obviously)
17:05:04 <kalev> so, I think groups aren't supposed to be a primary contact
17:05:06 <jwb> +1
17:05:08 <paragan> +1
17:05:20 <kalev> could we just add the group as a committer, instead of changing the primary contact?
17:05:30 <sgallagh> kalev: It's the primary on dozens of other packages
17:05:42 <jsmith> I'm +1 for this one, simply from the fact that there are a lot of mostly abandoned NodeJS packages :-/
17:05:51 <nirik> sure, +1 (as I was in ticket
17:06:17 <kalev> anyway, I am +1 too
17:07:19 <kalev> #agreed Reassign nodejs packages owned by 'patches' to group::nodejs-sig (+1:6, 0:0, -1:0)
17:07:40 * nirik can do that too
17:07:45 <jsmith> Thanks nirik
17:07:55 <kalev> thanks nirik
17:08:29 <maxamillion> +1
17:08:31 <maxamillion> sorry
17:08:34 * maxamillion got distracted
17:08:37 <kalev> np
17:08:39 <kalev> .fesco 1568
17:08:42 <zodbot> kalev: #1568 (F25 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1568
17:08:55 <kalev> #topic F25 Self Contained Changes
17:09:04 <kalev> #undo
17:09:04 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fb1d0b0d490>
17:09:07 <kalev> #topic #1568 F25 Self Contained Changes
17:09:16 <nirik> +1 fine with me
17:09:25 <kalev> there's one new self-contained change, https://fedoraproject.org/wiki/Changes/KojiInstallMedia
17:09:41 <kalev> +1 from me
17:09:46 <sgallagh> +1
17:09:46 <paragan> +1
17:10:06 <jsmith> +1 from me -- seems straightforward to me, and it seems releng is squarely on board :-)
17:10:07 <maxamillion> +1
17:10:52 <kalev> #agreed ​Koji Generates Installation Media self contained change accepted (+1:6, 0:0, -1:0)
17:11:13 <kalev> #topic #1573 Docker Layered Image maintainer guildelines, naming
17:11:13 <kalev> guidelines and review
17:11:13 <kalev> .fesco 1573
17:11:14 <kalev> https://fedorahosted.org/fesco/ticket/1573
17:11:15 <zodbot> kalev: #1573 (Docker Layered Image maintainer guildelines, naming guidelines and review) – FESCo - https://fedorahosted.org/fesco/ticket/1573
17:11:47 <nirik> sadly I had this marked to reply to on list, then didn't, so I am as guilty as everyone else.
17:11:54 <kalev> right, punt to next week then :)
17:12:12 <kalev> #topic Next week's chair
17:12:19 <kalev> who wants this glorious duty next week?
17:12:25 <nirik> It doesn't look like there is much interest in feedback on it tho... so not sure next week will help... but ok
17:12:44 <paragan> right
17:13:19 <jsmith> I'm happy to volunteer for next week
17:13:27 <maxamillion> jsmith++
17:13:30 <kalev> #action jsmith to chair next week
17:13:36 <kalev> thanks jsmith
17:13:41 <sgallagh> I'll volunteer for the week after
17:13:45 <jsmith> maxamillion: For what it's worth, I did read your guidelines, and didn't find anything wrong with them
17:13:48 <sgallagh> (I might not make it next week to volunteer)
17:13:51 <jsmith> maxamillion: Read them again, that is
17:14:00 <kalev> #topic Open Floor
17:14:03 <jsmith> sgallagh: Cool :-)
17:14:45 <kalev> anyone have anything else to discuss?
17:15:02 * jsmith has nothing further
17:15:48 <kalev> I can report how my tomato plant is doing on the balcony
17:15:55 <kalev> is that appropriate for open floor? :)
17:16:05 <kalev> 3 tiny tomatoes on! and bunch of flowers :)
17:16:19 <paragan> nice :)
17:16:20 <jsmith> kalev: My father-in-law sent me ten dead tomato plants in the mail yesterday :-/
17:16:30 <kalev> arr.
17:16:35 <kalev> I grew mine from the seed
17:16:42 <sgallagh> jsmith: That's... about as passive-aggressive as it gets, I think
17:16:52 <kalev> anyway. see you all next week then
17:16:54 <kalev> #endmeeting