15:00:42 <jforbes> #startmeeting FESCO (2019-06-21)
15:00:42 <zodbot> Meeting started Fri Jun 21 15:00:42 2019 UTC.
15:00:42 <zodbot> This meeting is logged and archived in a public location.
15:00:42 <zodbot> The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:42 <zodbot> The meeting name has been set to 'fesco_(2019-06-21)'
15:00:42 <jforbes> #meetingname fesco
15:00:42 <zodbot> The meeting name has been set to 'fesco'
15:00:42 <jforbes> #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor, ignatenkobrain
15:00:42 <jforbes> #topic init process
15:00:42 <zodbot> Current chairs: bookwar bowlofeggs contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:51 <nirik> morning.
15:00:56 <ignatenkobrain> .hello2
15:00:57 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:00:57 <dustymabe> .hello2
15:01:00 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
15:01:02 <bookwar> .hello2
15:01:03 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:01:16 <bgilbert> .hello2
15:01:17 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
15:01:27 <mhroncok> .hello churchyard
15:01:28 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
15:01:46 <bcotton> .hello2
15:01:47 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:02:11 <otaylor> .hello2
15:02:12 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:03:27 <mhroncok> sgallagh, ignatenkobrain, bookwar, contyk: congrats
15:03:45 <jforbes> So I wanted to start the meeting off with a welcome to ignatenkobrain
15:04:18 <ignatenkobrain> jforbes: mhroncok thanks 🙂
15:04:23 <nirik> welcome!
15:04:25 <jforbes> And a big thank you to bowlofeggs
15:04:28 <dustymabe> welcome all!
15:04:35 <nirik> and many thanks to bowlofeggs too... yeah.
15:04:47 <contyk> .hello psabata
15:04:48 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:05:09 <jforbes> since it seems we have quorum, let's get started
15:05:12 <contyk> mhroncok: thanks
15:05:16 <jforbes> #topic #2133 F31 System-Wide Change: Disable Root Password Login in SSH
15:05:17 <jforbes> .fesco 2133
15:05:17 <jforbes> https://pagure.io/fesco/issue/2133
15:05:19 <zodbot> jforbes: Issue #2133: F31 System-Wide Change: Disable Root Password Login in SSH - fesco - Pagure.io - https://pagure.io/fesco/issue/2133
15:06:46 <mhroncok> my proposal stands: Let's defer this change until the technical issues are solved.
15:07:28 <bookwar> mhroncok: but change is about approving the work to resolve the issues
15:07:42 <bookwar> mhroncok: or what do you mean as "resolved"?
15:08:08 <mhroncok> when there is a plan that all the relevant maintainers agree on
15:08:15 * nirik wonders if there could be a kickstart version of the checkbox too...
15:08:15 <jforbes> "I plan to start on this soon, so we have it in place well before branching" from the bz seemed like resolution of the planning change
15:09:06 <bookwar> i think the anaconda bug contains this plan and agreement, doesn't it?
15:09:15 <jforbes> That was how I read it
15:09:47 * mhroncok looks
15:10:02 <ignatenkobrain> I don't think that anaconda bug has exact plan on how to solve issue, but there are some possible solutions mentioned in a bug.
15:10:04 <mhroncok> it seems so, sorry
15:11:09 <ignatenkobrain> So I think I'm pretty confident +1 on this one. In worst case, contigency plan contains necessary things to be done and beta freeze seems like good time for it.
15:11:16 <otaylor> I thought from my reading there was a definite plan to proceed adding a checkbox (not entirely a fan...)
15:12:56 <mhroncok> if that checkbox is the plan, I'd be happier if the change page described that plan
15:12:59 <nirik> I think we could approve/vote now and if it's not done, it uses it's contingency plan.
15:13:37 <nirik> it does have a link to the bug, but it's not very detailed indeed.
15:13:47 <contyk> nirik: +1
15:15:53 <nirik> so? vote? defer?
15:15:54 <jforbes> So shall we vote then, or is there more to discuss?
15:16:44 <contyk> let's vote
15:16:46 <otaylor> I think we can vote to approve the change, and provide feedback if we think the anaconda changes need more careful planning
15:16:48 <mhroncok> +1 to the change. I can ask for the description update in the ticket.
15:16:55 <ignatenkobrain> vote+
15:17:04 <jforbes> +1 to the change as well
15:17:11 <bookwar> +1 for the change
15:17:20 <ignatenkobrain> +1 for the change
15:17:21 <nirik> +1 to the change. Should update the change page to have more info on the anaconda checkbox (where it is, what it does, etc)
15:17:21 <otaylor> +1 to the change (will put my own comment in the ticket about the anaconda part)
15:17:39 <contyk> +1, too
15:18:14 <jforbes> #agree 31 System-Wide Change: Disable Root Password Login in SSH is approved (+6,0,0)
15:18:38 <bcotton> jforbes: I think it's #agreed
15:19:04 <contyk> both works
15:19:19 <jforbes> #topic #2149 Proposal to change non-responsive maintainer policy
15:19:19 <jforbes> .fesco 2149
15:19:19 <jforbes> https://pagure.io/fesco/issue/2149
15:19:21 <zodbot> jforbes: Issue #2149: Proposal to change non-responsive maintainer policy - fesco - Pagure.io - https://pagure.io/fesco/issue/2149
15:19:23 <bcotton> oh, well nevermind then :-)
15:20:54 <mhroncok> let's vote on the general idea, later work on the exact wording and finally approve it then?
15:21:21 <nirik> I think we were getting close to wording...
15:21:27 <mhroncok> otherwise the bikeshedding might prevent us from moving this forward
15:21:33 <nirik> just perhaps need to consider the non maintainer case...
15:21:46 <jforbes> I think there is enough agreement on the general idea in the ticket. Do we want to defer a week to finish the wording? I don't see a point in 2 votes.
15:22:07 <nirik> how about we defer and also see if devel list has any input before we change it?
15:22:08 <mhroncok> that work for me as well
15:22:24 <jforbes> I can agree to that
15:23:01 <contyk> let's do that then :)
15:23:09 <nirik> who wants to start a thread? if no one else I can...
15:23:29 <ignatenkobrain> I suppose I can do that :)
15:24:05 <nirik> cool. thanks.
15:24:09 <jforbes> #agreed The proposal to change non-responsive maintainer policy is deferred while wording is fine tuned and it is discussed on devel list
15:24:28 <jforbes> #action ignatenkobrain to start a thread on the non-responsive maintainer policy
15:24:52 <jforbes> #topic #2151 F31 Self-Contained Change: Include several modules in the EFI build of Grub2 for security use-cases
15:24:52 <jforbes> .fesco 2151
15:24:53 <jforbes> https://pagure.io/fesco/issue/2151
15:24:54 <zodbot> jforbes: Issue #2151: F31 Self-Contained Change: Include several modules in the EFI build of Grub2 for security use-cases - fesco - Pagure.io - https://pagure.io/fesco/issue/2151
15:25:50 <nirik> this has buy in from grub2 maintainers right...
15:25:52 <contyk> it's quite fresh
15:26:32 <bcotton> nirik: yes, i confirmed that with them (the first time it was announced, they were surprised)
15:26:49 <nirik> yeah. If they are ok with it, then +1 here...
15:27:19 <jforbes> I am +1 here and was in the ticket
15:27:21 <ignatenkobrain> +1 to the change
15:27:33 <mhroncok> still 0
15:27:37 <nirik> although it really seems like it's sort of 1/2 done... to be a real useful change it would change anaconda to use it, but that can be down the road...
15:28:24 <jforbes> Yes, anaconda would make it more useful
15:30:35 <otaylor> +1
15:32:07 <otaylor> bcotton: the grub2 maintainres are listed on the proposal as owners, did that change from the initial state?
15:32:40 <bcotton> otaylor: iirc, the proposer listed them but hadn't talked to them about it first :-)
15:32:48 <mhroncok> oh my
15:33:02 <bcotton> otaylor: he has since gotten their buy-in on it
15:33:07 <jforbes> bookwar contyk?
15:33:21 <contyk> still +1
15:33:31 <jforbes> Oh right, you voted in ticket
15:33:41 <bookwar> +1 too
15:34:22 <jforbes> #agreed 31 Self-Contained Change: Include several modules in the EFI build of Grub2 for security use-cases is approved (+6,1,-0)
15:34:34 <jforbes> switched to agreed just for you bcotton :)
15:34:46 <mhroncok> :D
15:34:47 <bcotton> jforbes++ you're too good to me
15:34:48 <zodbot> bcotton: Karma for jforbes changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:34:54 <jforbes> #topic #2152 "backport" branches in src.fp.o for backports to coreos stable streams
15:34:54 <jforbes> .fesco 2152
15:34:54 <jforbes> https://pagure.io/fesco/issue/2152
15:34:55 <zodbot> jforbes: Issue #2152: "backport" branches in src.fp.o for backports to coreos stable streams - fesco - Pagure.io - https://pagure.io/fesco/issue/2152
15:35:20 <mhroncok> 19 hours ago, I have not yet seen this
15:35:24 <jforbes> So this one is super new, like filed as I was making the agenda, but dustymabe asked if we could discuss it. I said we could, but I couldn't guarantee a decision today
15:35:48 * mhroncok goes to read it
15:35:49 * nirik hasn't read anything this morning
15:35:53 <jforbes> mhroncok: Yes, super new, and not exactly straight forward
15:36:49 <dustymabe> +1
15:36:59 <dustymabe> raising awareness, not expecting a vote today
15:37:16 <dustymabe> also bgilbert and I are here to field questions if any exist
15:37:20 * bgilbert waves
15:37:48 <bcotton> dustymabe: should this be discussed on devel first?
15:37:48 <otaylor> I'd like to see more thought put into alternate possible solutions before we vote on this.
15:37:54 * nirik is ok with it, but it may end up being a ton of work... hard to say.
15:38:31 <dustymabe> bcotton: not sure, is that something you would suggest ?
15:38:32 <jforbes> dustymabe: as I just commented in ticket, why would there be multiple branches?  a single coreos-backport branch seems sufficient. If there were a 2nd CVE to address you would just add it to the first?
15:39:00 <bgilbert> jforbes: there might be separate bases for the `testing`, `stable`, and `next` streams
15:39:01 <mhroncok> dustymabe: how do you plan to "reuse" a branch?
15:39:12 <bgilbert> jforbes: I certainly hope that wouldn't be common
15:39:17 <bcotton> dustymabe: i would, but i'm only here in a non-voting capacity ;-)
15:39:55 <jforbes> dustymabe: Yes, package maintainers get picky about git branches. I am still annoyed at kernel branches that people accidentally (or intentionally) pushed WIP to years ago
15:40:17 <mhroncok> bcotton: I'm with you
15:40:17 <dustymabe> mhroncok: we'd basically merge what we want into that branch at the time we need it - the history wouldn't be pretty, but we proposed using tags to keep track of what commits were used for what rpms
15:40:24 <mhroncok> if this is not urgent, go trough devel@ first
15:40:49 <mhroncok> dustymabe: that sounds horrible
15:40:51 <dustymabe> otaylor: we're open to other more elegant solutions if they exist
15:41:19 <ignatenkobrain> I would prefer to have just one branch coreos-backports.. But generally I'm not happy with mid-branch fixes. +1 to mhroncok proposal
15:41:29 <dustymabe> there are several options discussed in the ticket. we talked with mattdm and releng (mohan) and it seems this proposal is what we came up with
15:42:20 <dustymabe> certainly open to better ideas :)
15:42:34 <dustymabe> mhroncok: bcotton: is the proposal to discuss on devel to see if there are better ideas out there ?
15:42:43 <mhroncok> dustymabe: realistically, when do you need a solution?
15:42:45 <mhroncok> dustymabe: yes
15:42:49 <jforbes> The reality is, there tend to be less than 10 critical CVE events in a given year. Things like MDS and SACK were multiple CVEs, but single events.
15:43:25 <jforbes> mhroncok: it is not a rush unless a disclosure suddenly makes it so :(
15:43:38 <dustymabe> jforbes: CVEs are a good example of when you'd need this, but there could be cases where we'd like to use this mechanism for regressions as well
15:43:46 <bookwar> dustymabe: so when you reuse branch, does it mean you reset it completely to point to another commit or you do merges and then get a very strange history
15:44:12 <dustymabe> bookwar: probably the strange history option - i don't think you can overwrite history in dist-git
15:44:32 <dustymabe> which is expected
15:44:53 <bgilbert> note that backports are not our preferred approach in any event.  we'd prefer to just take the new package when that seems safe.
15:44:54 <ignatenkobrain> bookwar: no, you have to merge the other branch/commits
15:45:10 <jforbes> You can do what we do with stabilization. We don't do a merge, just change everything and commit it as a "catch up commit"
15:45:46 <otaylor> I don't see a reason to have branches with crazy history in dist-git permanently
15:45:49 <dustymabe> bgilbert: do we have a good answer for mhroncok on the "when do you need a solution"?
15:45:58 <mhroncok> I have some ideas, but I need to read all the requirements, this is too quick for me
15:45:59 <otaylor> Just have a branch for each event named in some descriptive way
15:46:22 <mhroncok> otaylor: that. also we could have those branches live in nondefault ref namespace
15:46:28 <otaylor> and if that's really annoying people, delete the branch and just leave the tags
15:46:30 <jforbes> dustymabe: the only odd thing there, if something like a kernel bug is filed on some older version such as you ship, the default answer would likely be "try the current kernel"
15:46:43 <bookwar> dustymabe: is there an expectation, how many cases like this would appear in let's say one release cycle?
15:47:13 <bgilbert> dustymabe, mhroncok: we don't _need_ a solution for day 1 of the preview release.  it's a preview release; we can occasionally regress a bit.  but it'd be good to have an answer "soon".
15:47:18 <mhroncok> "nondefault refs namespace" is probably not a proper git term
15:47:21 <dustymabe> jforbes: correct. there would be some divergence here from the rest of fedora proper, which is why we hope we don't use this often
15:47:59 <bgilbert> otaylor, mhroncok: if something like that is workable, I'd personally prefer it
15:48:01 <jforbes> otaylor: You can't delete a branch in dist-git. And even if you could, if this was something that ever ships (and it sounds like it always would be), wouldn't it have to be kept for compliance reasons?
15:48:33 <mhroncok> jforbes: not if you keep the tag
15:48:35 <dustymabe> jforbes: well the tag would be there
15:48:46 <otaylor> jforbes: you'd need a branch or a tag to keep the commits from being garbage collected, but otherwise the commits are pointed to from koji, and that should be fine for compliance
15:49:14 <mhroncok> dustymabe, bgilbert: can we meet next week and discuss this (and not steal this fesco meeting)?
15:49:21 <dustymabe> absolutely
15:49:29 <bookwar> to be honest I don't get what is the problem with having more branches, Aren't tag and branch the similar concept in git, it is a pointer to a hash of a commit, isn't it?
15:49:33 <dustymabe> i was about to say I think we've gone far enough to let people think about it some
15:49:37 <bgilbert> mhroncok: I'm out next week :-(
15:49:50 <bgilbert> but in general, yes, happy to meet
15:49:59 <dustymabe> i'll be around, and the discussion can continue in the ticket too
15:50:22 <jforbes> Yes, I expect there will be plenty more discussion in ticket.
15:50:36 <bgilbert> +1
15:50:38 <jforbes> Anyway, I didn't promise a vote, but it was asked that I bring it up, and I did.
15:50:46 <dustymabe> thanks jforbes
15:50:48 <bgilbert> jforbes: thanks
15:50:49 <mhroncok> #action mhroncok to draft some more ideas next week, will put everything in the ticket (mostly based on what was said here)
15:50:53 <dustymabe> this was productive I think
15:51:18 <mhroncok> dustymabe: can you please drop me an e-mail? I'm on PTO today and might forget to do this next week
15:51:37 <dustymabe> sure
15:51:47 <mhroncok> thanks
15:51:52 <jforbes> #agreed voting on backport branches is deferred and will be further discussed in ticket
15:52:09 <jforbes> #topic Next week's chair
15:52:53 <jforbes> any takers?
15:53:01 <contyk> guess I could if there's no one else
15:53:22 <jforbes> Thanks contyk
15:53:37 <jforbes> #action contyk will chair next meeting
15:53:43 <jforbes> #topic Open Floor
15:54:07 <jforbes> Anyone have anything for open floor?
15:54:14 <mhroncok> onboarding ignatenkobrain
15:54:24 <mhroncok> do we need a ticket? there's plenty of stuff
15:54:42 <nirik> a ticket would be lovely. Happy to do stuff, but want it all tracked...
15:54:43 <mhroncok> groups, badges, mailing lists, pagure rights whatnot
15:54:53 <mhroncok> on it
15:54:53 <jforbes> Oh right. I forgot there is no magic script that does all of that
15:54:55 <nirik> and perhaps we could make a sop/wiki page?
15:55:13 <mhroncok> there is somehting
15:55:13 <ignatenkobrain> .fesco 2154
15:55:15 <zodbot> ignatenkobrain: Issue #2154: Update FESCo membership with elections results - fesco - Pagure.io - https://pagure.io/fesco/issue/2154
15:55:20 <nirik> and could get it so others besides me could do it all. ;)
15:55:20 <contyk> also, is it time for another whenisgood?
15:55:33 <mhroncok> https://docs.fedoraproject.org/en-US/fesco/Updating_Fedora_Engineering_Steering_Committee_Members/
15:55:43 <mhroncok> ignatenkobrain: is this meeting time OK for you, generally?
15:55:46 <ignatenkobrain> contyk: I'm fine with this time
15:56:22 <jforbes> Seems we are okay. Didn't even think about it since ignatenkobrain is typically involved in the meetings for one reason or another before elected
15:56:34 <bookwar> side-question, do we have anything fesco-specific at flock?
15:56:52 <jforbes> There is a modularity thing that we were tagged in
15:56:57 <bcotton> fwiw, i'm happy to handle the new/leaving member stuff as a matter of routine, if fesco is open to granting the appropriate privileges (and if you're not, i won't be hurt, i'll just keep filing tickets for you)
15:57:05 <jforbes> https://pagure.io/flock/issue/192
15:57:35 <mhroncok> nirik: https://pagure.io/fesco/issue/2156
15:57:38 <bookwar> jforbes: thanks
15:57:53 <nirik> bcotton: fine with me. don't want to overburden you, but if you are good with that being a FPM thing, fine
15:58:11 <ignatenkobrain> Do we actually have some FESCo session on a Flock?
15:58:14 <mhroncok> nirik, bcotton: +1
15:58:16 <ignatenkobrain> like where people can come and just ask us questions
15:58:30 <jforbes> bookwar: And we typically do a meeting in the same room, but it still has to be IRC based so that non attendees can participate
15:58:36 <contyk> we do panels sometimes
15:58:50 <contyk> it would be good to have one again
15:59:00 <ignatenkobrain> contyk: +1
15:59:06 <jforbes> There isn't a FESCo panel proposed that I see this year
16:00:06 <contyk> anyone wants to fix that?
16:00:09 <bcotton> for the sake of having a record in case anyone questions it: proposed #agreed the FPgM is authorized to update membership of FESCo mailing lists, Pagure groups, etc.
16:00:25 <bookwar> bcotton: +1
16:00:36 <contyk> +1
16:00:40 <mhroncok> bcotton: +1
16:00:52 <ignatenkobrain> +1
16:00:59 <ignatenkobrain> contyk: well, I guess I can open a flock proposal
16:01:11 <ignatenkobrain> Just need to find previous ones and copy description :)
16:01:16 <nirik> bcotton: +1 (and see me after meeting and we can sort out what you need for perms)
16:01:17 <contyk> ignatenkobrain++
16:01:31 <bookwar> maybe start from beginning, who doesn't go to flock?
16:01:35 <jforbes> It is late, round 2 selection is already in process isn't it?
16:01:38 <bcotton> nirik: ack
16:01:49 <ignatenkobrain> jforbes: cfp is open until 1st of July
16:02:07 <jforbes> Oh, forgot it was extended
16:02:25 <jforbes> I will be there, skipping Defcon for it
16:02:47 <ignatenkobrain> I'm coming to Flock, already bought a bus tickets
16:03:17 * nirik hopes to be there
16:03:21 <bookwar> assuming contyk, probably enough for a panel
16:03:53 <contyk> I'll be there
16:04:47 <bookwar> then ignatenkobrain files a request and we just come :)
16:04:50 <mhroncok> bcotton: sorry for the duplicate ticket :(
16:04:56 <bcotton> mhroncok: no worries :-)
16:05:05 <bcotton> mhroncok: two tickets are better than none :-)
16:05:39 <jforbes> If there is nothing else for open floor, will close in 2 minutes
16:05:40 <ignatenkobrain> #action ignatenkobrain to open FESCo Panel ticket for Flock
16:06:07 <bcotton> jforbes: can you #agreed my proposal for the record if the vote supports it?
16:06:19 <bcotton> jforbes: or #agree :p
16:06:33 <jforbes> +1
16:07:12 <jforbes> #agreed the FPgM is authorized to update membership of FESCo mailing lists, Pagure groups, etc. (+5,0,-0)
16:07:23 <bcotton> thanks :-)
16:07:43 <jforbes> #endmeeting