17:00:01 <zbyszek> #startmeeting FESCO (2023-03-28)
17:00:01 <zodbot> Meeting started Tue Mar 28 17:00:01 2023 UTC.
17:00:01 <zodbot> This meeting is logged and archived in a public location.
17:00:01 <zodbot> The chair is zbyszek. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:01 <zodbot> The meeting name has been set to 'fesco_(2023-03-28)'
17:00:01 <zbyszek> #meetingname fesco
17:00:01 <zbyszek> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, music, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:00:01 <zodbot> The meeting name has been set to 'fesco'
17:00:01 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mhayden mhroncok music nirik sgallagh zbyszek
17:00:04 <zbyszek> #topic init process
17:00:18 <zbyszek> .hello2
17:00:19 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
17:00:35 <decathorpe> .hi
17:00:37 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
17:00:39 <dcantrell> .hello2
17:00:41 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
17:01:06 <nirik> mornig
17:01:06 <nirik> morning even
17:01:20 <mhroncok> .hello churchyard
17:01:21 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:01:29 <zbyszek> We even have quorum.
17:01:46 <sgallagh> .hi
17:01:47 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:51 <zbyszek> I'll wait a minute and start the first topic.
17:02:19 <zbyszek> #topic #2966 request new group aiven-and-friends
17:02:20 <zbyszek> .fesco 2966
17:02:20 <zbyszek> .fesco 2929
17:02:21 <zodbot> zbyszek: Issue #2966: request new group aiven-and-friends - fesco - Pagure.io - https://pagure.io/fesco/issue/2966
17:02:24 <zodbot> zbyszek: Issue #2929: About cla_intel group - fesco - Pagure.io - https://pagure.io/fesco/issue/2929
17:02:38 <mhayden> .hello2
17:02:39 <zodbot> mhayden: mhayden 'Major Hayden' <mhayden@redhat.com>
17:02:43 <zbyszek> I made a proposal in the ticket…
17:03:08 <zbyszek> > Allow creation of groups for aiven and intel contributors. In the future, accept proposals for similar requests if reasonable.
17:03:26 <Eighth_Doctor> .hello ngompa
17:03:27 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:03:31 <nirik> I'm generally in favor. Would it be worthwhile to denote these somehow better?
17:03:47 <zbyszek> Could we have something in the name?
17:03:50 <nirik> I guess it doesn't matter.
17:03:51 <decathorpe> I would vote to approve this IFF there's a responsible person that's responsible for maintaining group memberships
17:03:52 <davide> .hello dcavalca
17:03:53 <zodbot> davide: dcavalca 'Davide Cavalca' <davide@cavalca.name>
17:04:13 <sgallagh> I'm with Fabio Valentini here
17:04:35 <nirik> well, each group would have a set of group managers? or do you mean something more?
17:04:41 <davide> I have a vested interest in this as well, as there's a lot of packages Meta cares about that group maintenance would make sense for
17:05:02 <Eighth_Doctor> it would have been useful when I was at Datto too :/
17:05:09 <mhroncok> I had bad experience chasing down maintainers when a package is maintained by a group
17:05:09 <davide> (for the record, we already have a FAS group for Meta but I've refrained for using it for package permissions so far as this discussion was still ongoing)
17:05:11 <mhayden> same with some packages for cloud providers
17:05:13 <Eighth_Doctor> I discarded it because we have a policy of not doing this
17:05:27 <Eighth_Doctor> (and because it's gone badly in the past)
17:05:31 <mhroncok> but I have no opinion as long as those groups are not used as primary bugzilla contacts
17:06:09 <mhayden> agreed on not being the primary contacts, for sure
17:06:11 <nirik> sadly, any group of people could be unresponsive. ;( With a group tho it's a bit more likely someone will respond I would think.
17:06:14 <decathorpe> I mean: somebody needs to be "around" to make sure the list of members of the group stays up-to-date. this isn't that much of a problem for SIG groups, but for employer based ones, this will get confusing fast
17:07:28 <nirik> well, if a employer group becomes unresponsive, their packages would just get orphaned like any other case no?
17:07:28 <davide> maybe for these groups we could have a toddler pinging them say every 6 months or so to make sure it's still up to date?
17:07:43 <zbyszek> decathorpe: that is a valid point. But I think we should allow a non-responsive-maintainer process for the group manager.
17:08:21 <decathorpe> zbyszek: that would be fine with me ... so long as we document that keeping things up-to-date is a responsibility that can be taken away ;)
17:08:22 <Eighth_Doctor> we also probably need to think about what happens with collective stalling or other bad maintainer behavior :(
17:08:24 <zbyszek> davide: hmmm, I wouldn't think this is necessary. We already have a process to ping maintainers if they are inactive, and that'd also cover this, even if a bit more slowly.
17:08:41 <nirik> I think this is just a way for companies to contribute more easily and we should let them use it... but it's subject to the same contraints as any other sig groups
17:08:58 * davide wonders if we should have a "guidelines for companies contributing to Fedora" doc somewhere
17:09:04 <decathorpe> well, we don't have a process for non-responsive groups ... only for individual users
17:09:25 <Eighth_Doctor> Davide Cavalca: it would need to be very carefully worded, but it would be useful to have
17:09:54 <decathorpe> it's not really clear what should happen if a group is co-maintainer and the package is neglected - open non-responsive maintainer bug for all group members?
17:10:07 <zbyszek> decathorpe: yeah, but this isn't a problem, because the group cannot be the primary maintainer. So people could do n-r-m-procedure against that person anyway, even if the group is a comaintainer.
17:10:10 <nirik> no, just the point of contact...
17:10:21 <davide> alternatively, should these groups have a mailing list?
17:10:26 <mhroncok> "because the group cannot be the primary maintainer" how so?
17:10:40 <nirik> all groups get mailing lists... thats where bugzilla sends the CC'ed bugs.
17:10:46 <decathorpe> mhroncok: because pagure-dist-git doesn't support it
17:11:01 <mhroncok> it does
17:11:02 <nirik> (but they are private as they get private bugs too)
17:11:05 <mhroncok> oh
17:11:09 <mhroncok> bugzilla override only
17:11:11 <decathorpe> only bugzilla assignee, but not owner
17:11:32 <mhroncok> so, if a package is primary contact by a group and nobody responds, we shoudl follow nonresponsive maintainer for a person?
17:11:57 <mhroncok> that should probably be explicitly said somewhere
17:11:58 <zbyszek> Yes. Either somebody responds, or the package gets a new owner.
17:12:00 <nirik> I don't think thats possible? at least unless I am misremembering
17:12:42 <davide> I've seen packages work around the "a group cannot be the maintainer" by using service users (not saying that's a good idea or what we should do here)
17:13:00 <nirik> I guess it is possible in some older cases, but not typically set anymore.
17:13:24 <nirik> yeah, that case... like firefox
17:13:39 <Eighth_Doctor> if the package was under group maint and the primary maint was part of that employer-group, then probably both need to be yanked
17:13:41 <nirik> (service user)
17:13:54 <Eighth_Doctor> nirik: rpm, lvm, dnf, and a few others are also in service users
17:14:06 <mhroncok> I guess the company that needs this could sync the maintainers of "their" packages by a script, or even manaully and this just makes it easier and more transparent, so it should be allowed
17:14:43 <nirik> yeah, if they are not responding, it can be orphaned...
17:14:54 <mhroncok> I just don't want folks to think "oh, this part of Fedora is maintained by 123Corp
17:15:25 <mhroncok> ... so I probably cannot contribute myself."
17:15:34 <davide> yeah, that would be an antipattern
17:15:51 <zbyszek> mhroncok: That'd be bad, but I don't think there's any difference from status quo.
17:16:09 <mhroncok> probably not, just thinking out loud
17:16:13 <zbyszek> There are packages which are maintained by a tight group of people, or just one person.
17:16:24 <mhroncok> my opinion is: this should be allowed, but needs to be worded carefully
17:16:56 <zbyszek> mhroncok: I assume my very careful wording is not good enough? I spent at least 40 seconds on it!
17:17:29 <mhroncok> zbyszek: which one exactly, sorry, I was not paying attention
17:18:11 <zbyszek> The first line at the start of this topic.
17:19:23 <zbyszek> OK, to move things along. Do we have consenus to allow this in general? We can figure out the exact wording outside of the meeting.
17:19:33 <mhroncok> > Allow creation of groups for aiven and intel contributors. In the future, accept proposals for similar requests if reasonable.
17:19:45 <mhroncok> +1 in to allow this general
17:19:53 <sgallagh> +1 to allow it in general
17:20:00 <dcantrell> +1 to allow it in general
17:20:07 <zbyszek> +1 too
17:20:14 <decathorpe> +1 in general, though I'd like to say that somebody needs to be responsible for keeping the groups up-to-date
17:20:25 <zbyszek> Eighth_Doctor: ?
17:20:29 <nirik> I wonder if it would be more clear to require -employer-sig or something, but I guess that only saves them responding to people who might join
17:20:36 <nirik> +1
17:20:53 <zbyszek> mhayden: ?
17:21:01 <Eighth_Doctor> +1 with some kind of denotation in the group name that it's employer centric
17:21:12 <mhayden> +1 from me
17:21:25 <nirik> I guess aven-and-friends implies some non employees
17:21:39 <zbyszek> #info The idea is approved in general and we'll try to figure out the text of the rule outside of the meeting.
17:21:53 <zbyszek> Anyone who want to work on this?
17:22:15 <nirik> I can try and propose something
17:22:30 <zbyszek> #action nirik to make a proposal
17:22:33 <zbyszek> Thanks!
17:22:33 <davide> happy to help wordsmith / provide feedback ok this as well
17:22:44 <zbyszek> #action davide to help also
17:23:11 <zbyszek> We have another totally interesting topic ;)
17:23:11 <zbyszek> #topic #2951 Proposal: policy for resubmitting rejected proposals
17:23:12 <zbyszek> .fesco 2951
17:23:13 <zodbot> zbyszek: Issue #2951: Proposal: policy for resubmitting rejected proposals - fesco - Pagure.io - https://pagure.io/fesco/issue/2951
17:23:25 <zbyszek> I should say riveting.
17:23:46 <nirik> is there anything new here?
17:23:55 <mhroncok> I asked a question on ticket 18 days ago, but unfortuantelly nobody replied
17:24:04 <zbyszek> Yeah, that's why I put it on the agenda.
17:24:16 <mhroncok> thanks
17:24:53 <zbyszek> I feel that the rules we have in place are sufficient and we don't need more rules.
17:25:29 <zbyszek> But I'd prefer to have a vote (whichever way it may go), rathern than keeping this open indefinitely.
17:26:00 <nirik> I think I am in the same boat
17:26:33 <mhroncok> let me try something
17:26:58 <mhroncok> this is a vote for perlimenary support. if it has some, I'll repost the proposal to devel before considerign a formal fesco vote...
17:28:17 <mhroncok> "Change proposals that are formally rejected may be submitted by reconsideration, but they must go through 1 additional week on the devel list before a fesco ticket is (re)opened for voting (following normal fesco voting rules)."
17:28:27 <mhroncok> please cast +1 if you would accept that
17:28:43 <dcantrell> I'm ok with that  +1
17:29:43 <Eighth_Doctor> does that mean we can no longer reject with request for amendments then?
17:29:51 <Eighth_Doctor> because we've done that a lot over the last few Fedora cycles
17:29:54 <decathorpe> does "rejected proposal as-is but would be approved immediately with only small changes or conditions" count as "formally rejected"
17:30:25 <music[m]> .hello music
17:30:25 <mhroncok> in my head, it does not count that way. will wordsmith that in if there is enogh support
17:30:27 <zodbot> music[m]: music 'Benjamin Beasley' <code@musicinmybrain.net>
17:30:34 <zbyszek> mhroncok: I think that often proposals are rejected because they fail to reach +5, rather than a majority of people being aginst. I think it should be fine to revote after a week if the vote was very close and the turnout wasn't complete.
17:31:00 <decathorpe> ok, I just don't want this to cause additional delays for things that could've been immediately approved with small conditions attached
17:31:06 <decathorpe> but otherwise +1
17:31:14 <zbyszek> So overall, as other people quickly pointed out too, we tie our hands with an onerous process that will just slow us down.
17:31:15 <nirik> yeah, I think theres a lot of corner cases... making it hard to come up with a formal rule
17:31:41 <zbyszek> If we repeat the vote on a controversial topic, we definitely should announce it widely and wait a bit.
17:31:56 <zbyszek> But sorry, -1 to this.
17:32:18 <mhroncok> zbyszek: I see where you are coming from, no need to be sorry
17:32:47 * decathorpe liked the "if it was announced as rejected on the mailing list, it needs to go through 'the process' again before another vote" idea
17:33:12 <mhroncok> if I cannot get at least +2 more support votes, I'll abandon this
17:35:32 <mhayden> i've read and reread the ticket around this a bunch of times but i honestly can't come to a decision. i may just be a dunce at understanding the problem.
17:35:59 <music[m]> zbyszek: Do you think that there could exist a similar proposal that didn’t slow down FESCo’s work unacceptably? Or is mhroncok’s proposal still categorically off base in your view?
17:37:00 <zbyszek> music[m]: I think I have a bigger issue. Trust in an institution like FESCo comes is based on perception of fairness and effectiveness.
17:37:15 <zbyszek> Not on having some complicated set of rules that is followed to the letter.
17:37:51 <zbyszek> Those precise rules degrade effectivness, while maybe causing a very minor increase in fairness.
17:37:55 <nirik> especially if we make our own rules and can override them or change them... ;)
17:38:18 <mhroncok> ok
17:38:42 <mhroncok> #info there is not enough support for mhroncok's amendment
17:38:53 <zbyszek> mhroncok++
17:38:54 <zodbot> zbyszek: Karma for churchyard changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:39:07 <zbyszek> #topic Next week's chair
17:39:08 <decathorpe> sad trombone
17:39:29 <zbyszek> I've (in some sense) done this for a few weeks. Somebody else's turn now.
17:40:28 <mhroncok> zbyszek++ for chairing
17:41:02 <zbyszek> I feel that I'm a bit too pushy sometimes. Please push back in those cases.
17:41:23 <zbyszek> We're having this via text, so it's not always easy to know what other people think.
17:41:25 * mhroncok is still unavailable for chairing this semester
17:42:18 <nirik> if no one else can do it, I can take a turn.
17:42:40 <zbyszek> #action nirik will chair the next meeting
17:42:45 <zbyszek> nirik, thanks.
17:42:49 <zbyszek> #topic Open Floor
17:42:51 <decathorpe> thanks
17:43:36 <music[m]> I could still support something like mhroncok’s suggestion, but I would really prefer any new rule on the topic to get everyone to at least -0. That’s obviously not required, but I don’t really want to push something over objections in this case.
17:43:46 <decathorpe> are there any opinions on https://pagure.io/fesco/issue/2965#comment-848616 other than "meh, it's fine"?
17:44:54 <mhroncok> I am more concerned with people merging packit PRs with blatant violations of the package guidelines than this, sorry.
17:44:59 <nirik> I'm open to other ideas to solve it, but this seemed the 'least bad' to me.
17:45:17 <decathorpe> ok, then feel free to close this issue.
17:45:42 <zbyszek> Yeah :(
17:45:51 <music[m]> I don’t have strong feelings either way.
17:45:52 <nirik> I wonder if bodhi could check if the build was made from a packit comit? but that might be too difficult
17:46:13 <music[m]> I would have feelings if the permissions extended beyond bodhi, I think.
17:46:25 <Eighth_Doctor> it would be easy to do since we have messages that include that information passed around infra
17:46:59 <mhroncok> i still think that packit won't create random updates
17:47:03 <nirik> I don't think bodhi listens to those types of messages.
17:47:16 <mhroncok> and if it does, we'll treat it like a bug, as if the bug was in bodhi to allow anybody to create random updates
17:47:23 <decathorpe> it wouldn't be so bad if koji did have any access controls
17:47:44 <nirik> lets play mousetrap. :)
17:48:42 <nirik> (ie, a rube goldberg collection of things all connected together), but anyhow...
17:48:53 <zbyszek> OK, I think we can wrap this up. Any more topics?
17:49:04 <smooge> thats the build system nirik
17:49:17 <zbyszek> that's fedora, smooge ;)
17:49:27 <nirik> yes, that was my joke. ;)
17:49:50 <zbyszek> See, if you turn it upside down and drop in a bit of cheese…
17:50:01 <dcantrell> there's no joking in fedora, it's all serious business here!
17:50:10 <nirik> 🧀
17:50:26 <zbyszek> OK, see y'all next week.
17:50:27 <zbyszek> #endmeeting