16:00:13 #startmeeting FESCO (2016-06-03) 16:00:13 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:13 The meeting name has been set to 'fesco_(2016-06-03)' 16:00:13 #meetingname fesco 16:00:13 #chair maxamillion dgilmore number80 jwb nirik paragan jsmith kalev sgallagh 16:00:13 The meeting name has been set to 'fesco' 16:00:13 Current chairs: dgilmore jsmith jwb kalev maxamillion nirik number80 paragan sgallagh 16:00:16 #topic init process 16:00:23 .hello sgallagh 16:00:24 sgallagh: sgallagh 'Stephen Gallagher' 16:00:25 morning 16:00:28 morning 16:00:28 .hello kevin 16:00:31 nirik: kevin 'Kevin Fenzi' 16:00:32 .hello hguemar 16:00:33 .hello pnemade 16:00:34 number80: hguemar 'Haïkel Guémar' 16:00:37 paragan: pnemade 'Parag Nemade' 16:01:17 ok, so we have quite a few things on agenda for this week 16:01:40 let's do the ones that are time critical first, the systemd thingie and graphical system upgrades 16:01:48 .hello jsmith 16:01:49 jsmith: jsmith 'Jared Smith' 16:01:54 kalev: Makes sense 16:01:59 WORKSFORME 16:02:00 #topic #1576 Evaluate Workstation graphical upgrade Change status 16:02:00 .fesco 1576 16:02:01 kalev: #1576 (Evaluate Workstation graphical upgrade Change status) – FESCo - https://fedorahosted.org/fesco/ticket/1576 16:02:01 https://fedorahosted.org/fesco/ticket/1576 16:02:45 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 .fesco 1576 16:02:50 kalev: #1576 (Evaluate Workstation graphical upgrade Change status) – FESCo - https://fedorahosted.org/fesco/ticket/1576 16:02:53 .hello maxamillion 16:02:53 kalev: Any chance of moving up the second round to Monday rather than Tuesday? 16:02:56 maxamillion: maxamillion 'Adam Miller' 16:02:58 sorry for being late 16:03:01 err, copy paste failure 16:03:02 https://fedorahosted.org/fesco/ticket/1576#comment:19 16:03:11 sgallagh: I'm gone on Monday, it's a holiday here 16:03:23 otherwise yeah 16:03:28 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 that seems a bit pessimistic to me. ;) 16:04:42 it's true though, yes? 16:04:57 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 kalev: how optimistic are you that can meet the deadline in your proposal? 16:05:03 well, if there's some horrible problem that blocks all updates, sure, it could be 16:05:07 *you 16:05:22 but thats pretty rare these days 16:05:36 sgallagh: you don't have proof of that. ;) 16:05:55 nirik: No one *ever* files a bug on any of my packages until they hit stable. 16:05:58 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 that does not mean they were not tested. 16:06:21 nirik: On several occasions, it surely did 16:06:33 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 kalev: so, those bugs would stop it going out ? or are they mostly minor? 16:06:43 kalev: well, if they are critical bugs (one that left users w/ unusable system) then -1, else we can discuss 16:07:11 some are annoying, like it doesn't handle network errors gracefully and stops the download when a download gets interrupted 16:07:27 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 I am not aware of anything that would leave users with unusable systems 16:07:28 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 I don't think so 16:08:06 I've got to be honest -- I'm a little nervous about leaving this to the last minute 16:08:06 better 16:08:41 then, we have to get QA feedback on the proposal 16:08:45 jsmith: +1 16:08:57 qa feedback/more testing would be very nice. 16:09:04 yep, agreed 16:09:04 adamw: ?? 16:09:11 kparal's been testing this quite a lot as it went along 16:09:32 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 well, depends on what you mean by sufficent. ;) but yeah, kparal has been testing and closing/filing new bugs 16:10:13 jsmith: Define "crunch time"? Because we're already in Freeze 16:10:28 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 there are a couple of issues kparal filed this week which look quite significant: 16:10:39 https://bugzilla.redhat.com/show_bug.cgi?id=1341151 16:10:40 sgallagh: Dang it -- you totally stole my punch line :-p 16:10:45 https://bugzilla.redhat.com/show_bug.cgi?id=1341159 16:10:47 those in the modified state are fixed 16:11:52 I'm more worried about the "upgrade silently fails" one, personally 16:12:22 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 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 the concern is always the unknown potential for edge cases that turn out to have broad impact (significant minority) 16:13:01 both those seem to be error handling/network issues. 16:13:54 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 hopefully they can get fixed by tuesday? 16:14:13 (since the net result is that the system remains in its pre-upgrade state) 16:15:47 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 so, I'm +1 to the plan... but of course sooner better than later for the next round of fixes... 16:16:09 kalev: 24 go/no-go is next thursday. 16:16:10 well, next friday is after go/no-go... 16:16:14 meetings next friday are a bit late. :P 16:16:43 Yeah, definitely too late :-( 16:17:59 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 (For the record, I'd vote -1 to such a request) 16:18:12 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 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 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 if it's not ready then ship anyway but not enable this feature 16:19:25 I *think* we decided weeks ago that this wasn't the official method for F24 16:19:43 nirik: yep, I'm planning on working on this next week, should be able to fix several of the issues 16:19:44 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 OK and how do the marketing and web folks feel about a last minute decision on this feature? 16:20:25 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 I didn't mean that it should block the release from going out 16:20:38 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 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 and mattdm wanted to know what to use in the release announcement. 16:21:43 so I am ok waiting until tuesday to decide if we want it at release or want to wait. 16:21:53 but we should make sure and have that conversation then 16:22:22 nirik: +1 16:22:23 oh, tuesday, not thursday? 16:22:42 kalev: We need lead time for the marketing folks. 16:22:59 fair enough 16:23:03 kalev: well, thursday seems late to set the wheels in motion... 16:23:07 and get the update stable and such 16:23:08 At Go/No-Go (and Readiness) it's final sign-off 16:24:22 would QA folks be ok with that? or prefer to just slip it out a week or two? 16:24:49 it might almost be better just to slip a week or two if this is something we're gunnign for 16:25:09 seems like a really narrow window 16:25:22 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 I think they meant not slipping Fedora but the release of this feature 16:25:55 Since it's not *strictly* tied to the Fedora release. 16:26:01 Because it's an update to the older Fedora 16:26:04 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 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 cmurf: no; that's downloaded from pkgdb. pkgdb flips the value once F24 is officially out 16:26:34 So that flip might happen a week after GA for many systems? 16:26:55 OK but it requires a download? So there's a delay? 16:27:23 And actually the delay is non-deterministic so it's no like everyone gets flipped over at the same time? 16:27:56 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 so everybody should get it about the same time 16:28:19 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 Alright so it kinda needs to work well and hopefully have few edge cases that are really bad. 16:28:41 In future updates, it will be simultaneous because F24+ will already have this feature. 16:28:45 And that's just difficult witout a lot of testing. 16:28:51 right 16:29:12 Really this is a trust issue due to lack of volume testing. No way around that really. 16:30:01 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 Ok so we're going with b. Fine. 16:30:45 I wonder if we could approach it more systematically 16:31:17 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 If there were a way to scale out the pkgdb switch flipping so it's not happening all at once... 16:31:34 adamw: like, blockers for this to go to stable? 16:31:40 kalev: probably primarily kparal, but sure. 16:31:48 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 cmurf: Well, in reality it's not like everyone is going to hit the upgrade button at the same time either 16:32:12 This is opt-in. 16:32:32 or everyone is going to update to the gnome-software+friends packages that offer it at the same time 16:32:32 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 I imagine plenty of people will play wait-and-see whether others have problems with it 16:32:48 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 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 cmurf: We could always unflip the pkgdb settnig 16:33:19 Flip it back to prerelease manually 16:33:26 * jsmith blinks... 16:33:28 (I'm spitballing here) 16:33:39 sgallagh: OK, just checking :-) 16:33:40 * kalev nods. 16:33:43 Yeah but if most everyone gets the switch flipped at about the same time, kinda pointless. 16:33:53 That's why I'm spitballing how to scale out such changes. 16:33:53 cmurf: Again, it doesn't cause an automatic upgrade 16:34:00 It requires a conscious decision to move 16:34:09 So not everyone is going to do that right away 16:34:14 I know, but there's also no automatic "don't click it we found a big bug!" notification. 16:34:17 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 sgallagh: please don't make pkgdb lie, fedfind relies on it. 16:34:40 it would then decide that 24 wasn't the current release any more and various things would go squiffy. 16:34:50 nirik: yep, let's do that, sounds like a good plan to me 16:34:52 (squiffy is a highly technical term) 16:34:54 adamw: That's almost worth it for the humor value alone! 16:35:17 "We are bringing back Classic F22" :) 16:35:22 squiffy sounds British 16:35:25 Heh 16:35:49 #action adamw and kparal to determine a list of blockers bugs for the graphical system upgrade feature 16:36:03 and then we'll see next week 16:36:09 ok, let's move on 16:36:31 #topic #1580 Systemd changes - Request - KillUserProcess behavior change 16:36:31 .fesco 1580 16:36:31 https://fedorahosted.org/fesco/ticket/1580 16:36:33 kalev: #1580 (Systemd changes - Request - KillUserProcess behavior change) – FESCo - https://fedorahosted.org/fesco/ticket/1580 16:36:50 zbyszek: you are up! 16:36:52 /me put a proposal in the ticket and zbyszek didn't seem opposed to it. 16:37:08 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 I'm ok with sgallagh's proposal too 16:38:04 yes +1 to sgallagh proposal in ticket 16:38:13 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 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 After all, Rawhide *is* for testing new things. 16:38:52 oh, actually I do have it enabled. I am not sure it's working as expected fully tho 16:38:59 I'm +1 to sgallagh proposal in the ticket also, I voiced that in ticket as well 16:39:40 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 zbyszek: should I file those enhancements I suggested on list upstream? (logging whats killed and a permissive mode) 16:40:33 nirik: No, I don't think so. It's on my agenda anyway. 16:40:44 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 zbyszek: ok, just checking. If you want to look at them thats great. 16:41:17 so, I think it's also a bit of a social issue here 16:41:18 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 zbyszek: are you going to propose a Change for F25 ? 16:41:34 zbyszek: That's not necessarily a safe assumption. 16:41:45 zbyszek: that seem presumptuous. 16:41:47 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 /me notes that Debian resolved not to accept that change in their downstream 16:41:49 but anyhoo 16:41:53 kalev: I think it's _mostly_ a social issue. ;) 16:42:11 nirik: i don't 16:42:14 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 I'm with jwb on this one 16:42:22 they'd be more open to the change 16:42:47 Well, if FESCo decides to reject the change, then there should be plenty of time to change it back. 16:42:51 I think that the problem is that both "sides" of this argument are acting from an incomplete set of expectations. 16:43:19 Lennart's point is valid: my expectation when I log out of all sessions is that anything I started exits. 16:43:22 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 *Except* certain tasks that I have different expectations for, like screen. 16:43:44 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 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 maxamillion: +1 16:44:06 nirik: I agree... 16:44:08 Which I use regularly to protect against network hiccups when doing long-running things that might not handle disruption well 16:44:22 maxamillion: I would certainly agree with that 16:44:43 And ultimately it's FESCo's job to decide *when* that point has been reached. 16:44:45 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 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 cmurf: unless they put it in the background, it won't even stay running before this change 16:45:14 why should it stay running ? 16:45:19 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 rdieter: By the same logic, switching it on to test it is a single edit. 16:46:08 But the problem is that switching the default without discussion or consideration of broken workflows is a problem 16:46:08 sgallagh: ok, to *me* this is for power users, not average joe 16:46:10 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 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 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 jwb: well, they think that will happen... I doubt very much it has to those people yet. 16:46:42 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 adamw: that's why I emphasised "as long as it's clearly documented" 16:46:52 maxamillion: I'm in the same boat: I think it's a good idea poorly executed so far. 16:46:54 sgallagh: +1 16:47:01 rdieter: fair enough, wasn't quite sure what you meant by that. 16:47:11 rdieter: documentation is not a solution 16:47:18 jwb: for powerusers it is 16:47:24 imho 16:47:26 i disagree 16:47:45 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 "poweruser" is a term people use when they want to say "that behavior is niche" 16:47:50 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 shrug, again, I still don't get it 16:48:15 nirik: +1 16:48:18 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 and then turn it on when we have a good plan there 16:48:56 kalev: To be fair, my proposal *suggested* the latter, but did not mandate it. 16:49:01 right 16:49:09 If upstream can add permissive logging feature we could enable that and see the scope of affected things better 16:49:19 zbyszek: would you be fine with this? 16:49:24 (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 mclasen___: oh? 16:49:39 mclasen___: oh, what breakage? 16:49:40 mclasen___: what? 16:49:43 mclasen___: Can you elaborate? 16:49:45 stuff leaks out of the session 16:49:49 thats why the change was made 16:49:53 mclasen___: note, it's only on in rawhide. 16:49:57 mclasen___: I discussed this with halfline yesterday 16:50:06 The result is that the behavior is the same as in F24 today. 16:50:12 you are a bit cavalier about 'this is just broken desktop stuff' 16:50:12 mclasen___: is that a net new breakage or just a continuation of breakage that's been around forever? 16:50:13 yes, there was a bug, but he seemed to think it was not serious enought to enable it. 16:50:22 well, to slip 16:50:24 maxamillion: continuation 16:50:27 And he and I decided that while it was unfortunate, it certainly wasn't blocker-worthy 16:50:28 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 its been around forever, but it is much more pronounced since user bus was introduced last august 16:50:47 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 ah 16:50:58 * nirik doesn't think it's just gnome, or just desktops... 16:51:10 if anything *that* is the sneaked in change tat wasn't sufficiently discussed 16:51:20 fun 16:51:27 nirik: +1 to asking for the logging functionality, FWIW 16:51:55 mclasen___: I agree :-) 16:51:56 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 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 But I agree it should have come in as a Change Proposal too 16:52:20 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 spstarr: Let's take that to #fedora-devel 16:52:43 It's off-topic 16:52:48 nirik: I don't want to promise to work on something that is likely to be rejected. 16:53:16 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 zbyszek: Would a statement from FESCo that we would carry that patch downstream be acceptable? 16:53:29 (if upstream rejected it) 16:53:38 well, it wasn't clear what they would accept... 16:53:55 yes, definitely, we can patch things downstream if needed 16:54:00 and the issue got spammed and the people with pitchforks and torches showed up and they closed it. 16:54:37 Well it ended up on Twitter so... pitchforks and torches go along with that. 16:54:41 yep 16:55:09 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 we can try and sort it, we are drifting off topic. ;) 16:56:05 anyway, I think mostly everybody seems fine with sgallagh's propsal 16:56:16 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 kalev: Probably best to get an actual count, though 16:56:28 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 Yes. 16:56:35 good. 16:56:46 +1 to sgallagh's proposal from me 16:56:49 ok, let's vote on sgallagh's proposal; sgallagh can you write it here once more for posterity? 16:57:06 thanks zbyszek for all your work on this and answering peoples dumb questions. :) It's appreciated. 16:57:06 + to sgallagh's proposal 16:57:10 +1 to sgallagh's proposal 16:57:12 * maxamillion can't type 16:57:23 +1 (for the record) 16:57:33 +1 16:57:43 +1 16:57:47 +1 16:58:01 zbyszek: Yes, please understand that we're appreciative, but we also need to balance expectations. And it's a polarizing issue. 16:58:10 +1 16:58:36 ok, that's +6 16:59:22 sgallagh: +1 17:00:05 +1 (again) 17:00:23 nirik, sgallagh: thanks. 17:00:48 #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 ok, moving on 17:01:11 #topic #1578 F25 System Wide Change: Use /etc/repos.d as default reposdir 17:01:14 .fesco 1578 17:01:15 kalev: #1578 (F25 System Wide Change: Use /etc/repos.d as default reposdir) – FESCo - https://fedorahosted.org/fesco/ticket/1578 17:01:17 https://fedorahosted.org/fesco/ticket/1578 17:01:45 this one has been canceled by the Change owner 17:01:53 jkurik wanted us to note that this has been cancelled 17:01:57 I just left it open for awareness 17:01:58 noted, thanks! 17:02:12 #topic #1581 Unresponsive maintainer: asaf 17:02:12 .fesco 1581 17:02:13 https://fedorahosted.org/fesco/ticket/1581 17:02:13 kalev: #1581 (Unresponsive maintainer: asaf) – FESCo - https://fedorahosted.org/fesco/ticket/1581 17:02:56 looks like they've left years ago, I guess it makes sense to orphan all of asaf's packages? 17:03:19 Proposal: orphan all of asaf's packages 17:03:21 +1 17:03:26 there's only 2. ;) but yeah, +1 17:03:30 +1 from me (sadly) 17:03:32 +1 17:03:42 +1 17:03:49 +1 17:04:01 +1 17:04:05 #agreed orphan all of asaf's packages (+1:7, 0:0, -1:0) 17:04:14 nirik: will you do that? 17:04:28 sure. can do 17:04:34 perfect, thanks 17:04:36 nirik++ 17:04:44 #topic #1582 Reassign nodejs packages owned by 'patches' to 17:04:44 group::nodejs-sig 17:04:44 .fesco 1582 17:04:45 https://fedorahosted.org/fesco/ticket/1582 17:04:45 kalev: #1582 (Reassign nodejs packages owned by 'patches' to group::nodejs-sig) – FESCo - https://fedorahosted.org/fesco/ticket/1582 17:05:00 +1 from me (obviously) 17:05:04 so, I think groups aren't supposed to be a primary contact 17:05:06 +1 17:05:08 +1 17:05:20 could we just add the group as a committer, instead of changing the primary contact? 17:05:30 kalev: It's the primary on dozens of other packages 17:05:42 I'm +1 for this one, simply from the fact that there are a lot of mostly abandoned NodeJS packages :-/ 17:05:51 sure, +1 (as I was in ticket 17:06:17 anyway, I am +1 too 17:07:19 #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 Thanks nirik 17:07:55 thanks nirik 17:08:29 +1 17:08:31 sorry 17:08:34 * maxamillion got distracted 17:08:37 np 17:08:39 .fesco 1568 17:08:42 kalev: #1568 (F25 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1568 17:08:55 #topic F25 Self Contained Changes 17:09:04 #undo 17:09:04 Removing item from minutes: 17:09:07 #topic #1568 F25 Self Contained Changes 17:09:16 +1 fine with me 17:09:25 there's one new self-contained change, https://fedoraproject.org/wiki/Changes/KojiInstallMedia 17:09:41 +1 from me 17:09:46 +1 17:09:46 +1 17:10:06 +1 from me -- seems straightforward to me, and it seems releng is squarely on board :-) 17:10:07 +1 17:10:52 #agreed ​Koji Generates Installation Media self contained change accepted (+1:6, 0:0, -1:0) 17:11:13 #topic #1573 Docker Layered Image maintainer guildelines, naming 17:11:13 guidelines and review 17:11:13 .fesco 1573 17:11:14 https://fedorahosted.org/fesco/ticket/1573 17:11:15 kalev: #1573 (Docker Layered Image maintainer guildelines, naming guidelines and review) – FESCo - https://fedorahosted.org/fesco/ticket/1573 17:11:47 sadly I had this marked to reply to on list, then didn't, so I am as guilty as everyone else. 17:11:54 right, punt to next week then :) 17:12:12 #topic Next week's chair 17:12:19 who wants this glorious duty next week? 17:12:25 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 right 17:13:19 I'm happy to volunteer for next week 17:13:27 jsmith++ 17:13:30 #action jsmith to chair next week 17:13:36 thanks jsmith 17:13:41 I'll volunteer for the week after 17:13:45 maxamillion: For what it's worth, I did read your guidelines, and didn't find anything wrong with them 17:13:48 (I might not make it next week to volunteer) 17:13:51 maxamillion: Read them again, that is 17:14:00 #topic Open Floor 17:14:03 sgallagh: Cool :-) 17:14:45 anyone have anything else to discuss? 17:15:02 * jsmith has nothing further 17:15:48 I can report how my tomato plant is doing on the balcony 17:15:55 is that appropriate for open floor? :) 17:16:05 3 tiny tomatoes on! and bunch of flowers :) 17:16:19 nice :) 17:16:20 kalev: My father-in-law sent me ten dead tomato plants in the mail yesterday :-/ 17:16:30 arr. 17:16:35 I grew mine from the seed 17:16:42 jsmith: That's... about as passive-aggressive as it gets, I think 17:16:52 anyway. see you all next week then 17:16:54 #endmeeting