15:00:53 <sgallagh> #startmeeting FESCO (2018-06-25)
15:00:53 <zodbot> Meeting started Mon Jun 25 15:00:53 2018 UTC.
15:00:53 <zodbot> This meeting is logged and archived in a public location.
15:00:53 <zodbot> The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:53 <zodbot> The meeting name has been set to 'fesco_(2018-06-25)'
15:00:53 <sgallagh> #meetingname fesco
15:00:53 <zodbot> The meeting name has been set to 'fesco'
15:00:53 <sgallagh> #chair nirik, maxamillion, jsmith, jwb, zbyszek, tyll, sgallagh, contyk, bowlofeggs
15:00:53 <zodbot> Current chairs: bowlofeggs contyk jsmith jwb maxamillion nirik sgallagh tyll zbyszek
15:00:53 <sgallagh> #topic init process
15:01:04 <zbyszek> Hello everyone
15:01:05 <jwb> hello
15:01:06 <zbyszek> .hello2
15:01:07 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:01:08 <sgallagh> .hello2
15:01:10 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:12 <nirik> morning
15:01:18 <mhroncok> .hello2
15:01:19 <zodbot> mhroncok: Sorry, but you don't exist
15:01:25 <mhroncok> zodbot: oh no!
15:01:34 <tyll> .hello till
15:01:34 <sgallagh> mhroncok: It only works if your IRC nick matches your FAS name :)
15:01:34 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
15:01:49 <sgallagh> Or maybe if it matches your saved IRC nick in FAS? Not sure.
15:01:49 <contyk> .hello psabata
15:01:50 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:59 <mhroncok> sgallagh: it doesn't, my IRC nick is in FAS
15:02:00 <sgallagh> contyk: Aren't you on PTO today?
15:02:06 <contyk> yeah, I am
15:02:08 <zbyszek> tyll: mhroncok wanted a script to file ftbfs, I thought you might have one
15:02:33 <gbcox> hello
15:03:05 <tyll> zbyszek: mhroncok: yes, I have some code that worked more or less
15:03:31 <sgallagh> OK, we have quorum, so shall we begin?
15:03:44 <sgallagh> #topic #1918 Proper Conditionalization of default systemd processes
15:03:44 <sgallagh> .fesco 1918
15:03:46 <zodbot> sgallagh: Issue #1918: Proper Conditionalization of default systemd processes - fesco - Pagure - https://pagure.io/fesco/issue/1918
15:04:05 <sgallagh> So, zbyszek asked to bring this to the meeting, so I'll let him lead the discussion.
15:04:33 <zbyszek> Right
15:04:55 <zbyszek> So I think FESCo should make some kind of a statement about the general guidelines here.
15:05:12 <zbyszek> https://pagure.io/fesco/issue/1918#comment-518092 contains text that is nice,
15:05:18 <zbyszek> thanks sgallagh,
15:05:36 <sgallagh> Happy to help
15:05:41 <zbyszek> but I'd like to add one sentence to it, that
15:06:04 <zbyszek> specifies that activation is *desired* if possible automatically.
15:07:07 <zbyszek> I don't have a specific suggestion for wording though.
15:07:08 <zbyszek> EOF
15:07:16 <sgallagh> To rephrase, you mean that we should say "If this service CAN autostart in the presence of appropriate hardware, then it should"?
15:07:34 <zbyszek> Yes, that's one way to put it.
15:08:02 <contyk> that sounds reasonable
15:08:19 <sgallagh> I'm open to better phrasings, but I was mostly just trying to confirm I understood your suggestion
15:08:32 <tyll> IMHO the third bullet (If there is value in the service optionally failing...) is too vague, it only contains the info to check if an existing implementation would be ok but does not guide maintainers to create a solution themselves, e.g. what would the userspace tool look like and what data would be stored in /var
15:08:54 <sgallagh> tyll: Well, these aren't packaging guidelines.
15:09:08 <sgallagh> The idea was for us to give an overall goal and let FPC figure out the exact details
15:09:30 <tyll> sgallagh: ah, I see
15:09:41 <sgallagh> Though I realize I maybe overspecified in a few places in order to make sure the point wasn't vague
15:10:15 <zbyszek> I don't know if dropping a configuration file counts as "proper userspace tool" though.
15:10:27 <zbyszek> This would the most natural mechanism.
15:10:47 <sgallagh> Eh, it's something performed in userspace.
15:11:06 <sgallagh> I didn't intend that to imply a dedicated tool, but I probably phrased it wrong.
15:11:21 <sgallagh> probably I should have chosen the word "mechanism"
15:12:03 <zbyszek> Maybe the third point should be made more generic, like "this *may* be made available using an opt-in userspace mechanism or by storing information about detected hardware on disk."
15:12:34 <sgallagh> zbyszek: I'm fine with that rephrasing
15:12:35 <sgallagh> +1
15:14:19 <tyll> IMHO it would be great to have only one mechanism (modulo the service name) that would work for all services
15:14:32 <zbyszek> tyll: that's unrealistic
15:14:42 <sgallagh> Yeah, I don't think that's achievable.
15:15:58 <tyll> why? or what do you mean by mechanism?
15:16:34 <tyll> if the mechanism is just a config file, the service-specific part can still do whatever it likes with the information that a service should be enforced
15:17:23 <tyll> I assumed the mechanism would be something like echo "force-enable=rngd.service" > /etc/sysconfig/enforced-services.d/rngd.service or similar
15:17:25 <sgallagh> tyll: If you want to help FPC design a generic solution, that's fine with me but I think it's out of scope for this meetnig
15:18:00 <tyll> I do not want to design the solution just have this as a requirement
15:18:18 <contyk> if the services could fail with some (to be defined) hardware-not-available code, it could be generic
15:18:29 <contyk> but indeed, that's not for this meeting
15:18:42 <zbyszek> tyll: I think that various services already implement this in custom ways (I know of smartd, and the proposed solution in rngd.service), and unifying that is a lot of talking with maintianers for little gain
15:20:18 <zbyszek> OK, can we also add point 0 to sgallagh's list like this: "If certain hardware can be used without configuration, services which provide this support for this should be enabled by default." ?
15:20:37 <sgallagh> zbyszek: +1
15:22:42 <nirik> can someone pastebin or add a comment with the current proposal? I'm having trouble following...
15:22:42 <sgallagh> contyk, tyll, nirik, jwb ?
15:22:47 * nirik has more coffee
15:22:51 <contyk> +1
15:23:02 <tyll> zbyszek: IMHO creating a uniform interface for our users is the purpose of a distribution
15:23:40 <nirik> I'm fine with the point 0 above.
15:23:52 <jwb> +1
15:24:23 <tyll> +1 (since it does not contradict having a uniform interface)
15:25:05 <zbyszek> tyll: I think a uniform mechanism would be nice, but it should be a seperate ticket
15:25:22 <sgallagh> I added https://pagure.io/fesco/issue/1918#comment-518281 as an updated version of the proposal just now
15:25:38 <zbyszek> I added https://pagure.io/fesco/issue/1918#comment-518280 just before you ;)
15:25:55 * sgallagh sighs
15:26:43 <zbyszek> My version includes the rephrasing
15:26:45 <sgallagh> I think they're fundamentally identical, so +1 to either :)
15:27:09 <sgallagh> zbyszek: So did mine, albeit I kept them as separate bullets
15:27:22 <zbyszek> no, that's the added point
15:27:26 <sgallagh> (Well, I edited that after the initial submit)
15:27:38 <jwb> can we not do that?  bouncing back and forth between proposals here and proposals in the tickets are confusing enough for people active in the meeting.  it'll be even harder for people reading the minutes later
15:27:38 <sgallagh> refresh, we may have just crossed streams
15:27:55 <sgallagh> jwb: I edited it before I posted the link in here
15:28:03 <jwb> you're missing my point
15:28:06 <sgallagh> I think that zbyszek probably read the original
15:28:13 <sgallagh> Perhaps I am
15:28:25 <jwb> put the proposal we're voting on as text in this meeting
15:28:27 <zbyszek> sgallagh: you're right, they are essentially identical
15:28:39 <zbyszek> jwb: it's ~20 lines
15:28:50 <jwb> and?
15:28:53 <nirik> +1 to either.
15:28:55 <zbyszek> It seems better to include just the link
15:29:01 <jwb> ok, whatever
15:29:11 <zbyszek> OK, so +1 to sgallagh's proposal in https://pagure.io/fesco/issue/1918#comment-518281
15:29:16 <sgallagh> +1
15:29:22 <zbyszek> (mine is duplicate)
15:30:58 <nirik> +1 still
15:31:02 <contyk> also +1
15:32:02 <jwb> +1
15:32:47 <sgallagh> tyll: ?
15:32:54 <sgallagh> oh, he was +1 above
15:32:56 <tyll> is storing state on the disk in /var a mechanism for itself to make the service failing? the "one of the following" implies to me that only one of both sub-bullets can be used but to me it seems that they both work together
15:33:05 <tyll> but in general +1
15:33:08 <sgallagh> #agreed FESCo will submit the proposal in https://pagure.io/fesco/issue/1918#comment-518281 to the FPC (+6, 0, -0)
15:33:16 <sgallagh> tyll: They don't have to be mutexed.
15:33:49 <tyll> sgallagh: IMHO then "on of the" needs to be removed from the sentence
15:33:51 <sgallagh> #topic #1913 F29 Self Contained Change: User PATH Prioritization
15:33:52 <sgallagh> .fesco 1913
15:33:53 <zodbot> sgallagh: Issue #1913: F29 Self Contained Change: User PATH Prioritization - fesco - Pagure - https://pagure.io/fesco/issue/1913
15:34:04 <sgallagh> I'm sure this topic will go much quicker...
15:34:08 <mhroncok> :D
15:34:37 <contyk> definitely
15:34:41 <tyll> +1
15:34:54 <sgallagh> So, I'm of the opinion that the burden of proof needs to be on those proposing it. What is the clear advantage to making this change?
15:34:58 <zbyszek> +1 (as in the ticket)
15:35:16 <mhroncok> sgallagh: the clear advantage is that fi user pip/etc installs something, they can use it
15:35:20 <mhroncok> everytime, tight away
15:35:25 <contyk> I think everyone who has apps in those paths is capable to change their $PATH
15:35:26 <mhroncok> right
15:35:34 <nirik> +1
15:35:35 <contyk> and having it enabled by default is just risky
15:35:49 <sgallagh> I'm not convinced by the risk argument, particularly.
15:36:10 <zbyszek> sgallagh: also uniformity with Debian/Ubuntu/Anaconda/etc.
15:36:14 <sgallagh> I think I agree that if someone has enough control to put junk in ~/bin, then they have enough control to also edit .bashrc
15:36:33 <mhroncok> they put junk in there by running "whatnot install foobar"
15:36:47 <tyll> just being capable to fix something that is broken does not imply that it is a good idea to require people to fix bugs in the default settings
15:37:02 <jwb> i'm +1 to the change
15:37:34 <zbyszek> sgallagh: Then there's the more subtle argument that pip-installed modules override the the system modules, but pip-installed executables in ~/.local/bin do not, which causes issues for users
15:37:43 <jwb> argumentation requiring people to edit PATH seems to be saying "we could make your life easier, but we won't because you can do that yourself"
15:37:58 <sgallagh> jwb: Yeah, I agree with that.
15:38:19 <contyk> zbyszek: that's a reasonable argument
15:39:22 <mhroncok> also, there's the general asumption that what's closer to the user should have higher priority
15:39:45 <mhroncok> at least it works with configuration etc.
15:39:59 <zbyszek> bowlofeggs was +1 in the ticket
15:40:05 <contyk> I abstain
15:40:14 <sgallagh> I'm a weak +1 here, so I guess that makes it +6 now
15:41:10 <sgallagh> #agreed FESCo accepts the F29 Self Contained Change: User PATH Prioritization (+6, 1, -0)
15:41:22 <mhroncok> pepare for the shitstorm
15:41:31 * sgallagh turns on the fan
15:41:40 * zbyszek goes on PTO tomorrow
15:41:45 <sgallagh> zbyszek: Clever!
15:41:52 <sgallagh> #topic Next Week's Chair
15:42:10 <contyk> I won't be around next week
15:42:19 <zbyszek> I might not be either, not sure yet
15:43:01 <sgallagh> Well, if we resolve everything in tickets, we won't need to meet :)
15:43:34 <zbyszek> There's the BLS ticket, which is another beast
15:43:44 <nirik> I suppose I can do it...
15:44:28 <sgallagh> nirik: Thank you, nirik.
15:44:39 <sgallagh> #info nirik to chair the 2018-07-02 meeting
15:44:45 <nirik> (if there is one)
15:44:48 <sgallagh> #topic Open Floor
15:45:40 <sgallagh> General impressions of the new ticket policy? I think it's working so far.
15:46:00 <contyk> well, the meeting sure was shorter
15:46:02 <nirik> seems fine, kinda early to tell.
15:46:15 <contyk> but what nirik says
15:46:34 * sgallagh nods.
15:46:48 <sgallagh> OK, if no one has anything else, I'll set the fuse
15:46:53 <mhroncok> BTW JFYI The Python 3.7 change update: 2096 packages built, 170 wait for deps, 176 FTBFS
15:47:20 <nirik> mhroncok: when is it planned to merge back in?
15:47:21 <tyll> Based on the feedback on the list I was wondering if we should maybe just close tickets that were handled withouth a meeting when preparing the agenda and mention closed tickets there as well to create the digest view
15:47:26 <mhroncok> nirik: once ready
15:47:43 <mhroncok> nirik: I don't really know what does that mean, but will coordiante with QA
15:47:49 <nirik> well, what does ready mean? no dep issues? no fails to build?
15:47:58 <nirik> ok.
15:48:06 <mhroncok> no fails to build is nonrealistic
15:48:13 <nirik> yeah, I agree.
15:48:13 <mhroncok> there are packages that ftbfs since f26
15:48:17 <contyk> mhroncok: anything special we should be doing if we want to kill some of those packages?
15:48:22 <mhroncok> that has nothing to do with this change
15:48:23 <sgallagh> tyll: That makes good sense. Would you mind updating the FESCo Meeting SoP page?
15:48:32 <nirik> I think making sure critpath is working and all we need for composes would be the best bar
15:48:40 <nirik> tyll: +1
15:48:41 <mhroncok> contyk: the new policy is there, so shoudl amke it easier after ~6 months
15:50:06 <mhroncok> nirik: there is still libreoffice and gcc and kernel-tools, so i think is't not going to be merged any time soon
15:50:26 <mhroncok> and ansible :D
15:50:38 <nirik> ugh, ok. The longer it is there, the worse...
15:50:39 <tyll> sgallagh: I will
15:50:43 <sgallagh> Thank you
15:50:45 <nirik> oh? I wasn't aware...
15:50:52 <mhroncok> nirik: I'm doing my best
15:51:23 <tyll> #action till will update the SoP page to add digest info about tickets that were handled without a meeting
15:52:09 <zbyszek> #info The Python 3.7 change is in progress: 2096 packages built, 170 wait for deps, 176 FTBFS
15:52:48 <mhroncok> bye, thanks
15:52:56 <zbyszek> mhroncok++
15:52:56 <zodbot> zbyszek: Karma for churchyard changed to 4 (for the f28 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:53:10 * nirik can look at the ansible fail and/or ask upstream to.
15:53:16 <nirik> mhroncok++
15:53:16 <zodbot> nirik: Karma for churchyard changed to 5 (for the f28 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:53:17 <sgallagh> mhroncok++
15:53:19 <zodbot> sgallagh: Karma for churchyard changed to 6 (for the f28 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:53:23 <sgallagh> tyll++
15:53:23 <zodbot> sgallagh: Karma for till changed to 8 (for the f28 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:53:34 <sgallagh> OK, any other topics today?
15:55:39 <sgallagh> Alright, thanks for coming folks
15:55:42 <sgallagh> #endmeeting