17:00:24 <Eighth_Doctor> #startmeeting FESCO (2023-01-10)
17:00:24 <zodbot> Meeting started Tue Jan 10 17:00:24 2023 UTC.
17:00:24 <zodbot> This meeting is logged and archived in a public location.
17:00:24 <zodbot> The chair is Eighth_Doctor. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:24 <zodbot> The meeting name has been set to 'fesco_(2023-01-10)'
17:00:27 <Eighth_Doctor> #meetingname fesco
17:00:27 <zodbot> The meeting name has been set to 'fesco'
17:00:37 <Eighth_Doctor> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, music, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:00:37 <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:43 <dcantrell> .hello2
17:00:44 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
17:00:51 <sgallagh> .hi
17:00:52 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:07 <mhayden> .hi
17:01:08 <zodbot> mhayden: mhayden 'Major Hayden' <mhayden@redhat.com>
17:01:31 <Eighth_Doctor> .hello ngompa
17:01:32 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:01:53 <mhroncok> .hello churchyard
17:01:54 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:02:09 <bcotton> .hello2
17:02:10 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:02:23 <nirik> morning
17:02:50 <Eighth_Doctor> I guess we have enough people here now
17:02:53 <Eighth_Doctor> #topic init process
17:03:46 <Eighth_Doctor> we have only one thing on the agenda
17:04:26 <Eighth_Doctor> #topic #2870 Change proposal: Replace DNF with DNF5
17:04:48 <Eighth_Doctor> .fesco 2870
17:04:50 <zodbot> Eighth_Doctor: Issue #2870: Change proposal: Replace DNF with DNF5 - fesco - Pagure.io - https://pagure.io/fesco/issue/2870
17:04:50 <mhayden> i hear it's 25% better than DNF4
17:04:54 * mhayden will be here all week
17:06:42 * nirik hasn't read that github discussion yet
17:07:32 <dcantrell> the proposal rewrite looks better and answered a lot of small questions I had
17:07:41 <dcantrell> nirik: are you talking about the discussion about what to name it?
17:07:46 <sgallagh> I've skimmed it, and I think the only real outstanding question is the binary name on-disk?
17:07:51 <mhroncok> https://github.com/rpm-software-management/dnf5/discussions/210
17:08:24 <nirik> dcantrell: yeah, readin now
17:09:04 <mhroncok> "Whenever the update is finished, can there be an additional comment period for the revised proposal on devel@ before this is voted on by FESCo?"
17:09:07 <dcantrell> ah, yeah, I added my comments.  honestly, I don't really care too much about the name on disk.  the reality is that Fedora will have to support the existing (and new-ish dnf5) names regardless of what the file or package is called
17:09:09 <mhroncok> https://pagure.io/fesco/issue/2870#comment-832295
17:09:34 <mhayden> i just care that a user in the new release can run 'dnf' and get what they expect, even if they have zero knowledge that dnf even changed
17:09:38 <mhroncok> "I will send the note when the rewrite is finished"
17:09:49 <dcantrell> mhayden: I agree, and that's what I gather from the proposal
17:09:51 <mhroncok> have the devel@ thing ever happened
17:09:56 <mhroncok> s/have/has/
17:09:57 <mhroncok> ?
17:09:59 <sgallagh> not that I saw
17:10:11 <sgallagh> At least, not as a discrete conversation
17:10:15 <dcantrell> mhroncok: it looks like he posted a comment in the ticket rather than posting on the list
17:10:16 <mhroncok> sigh
17:10:18 * zbyszek had a meeting run over, but is here now
17:11:01 <nirik> yeah, I think it looks pretty reasonable with option 3 there... but wouldn't hurt to pass thru the list again...
17:11:10 <music[m]> .hello music
17:11:11 <zodbot> music[m]: music 'Benjamin Beasley' <code@musicinmybrain.net>
17:11:41 <dcantrell> let's announce it today for another week of comments and then vote next week
17:11:55 <dcantrell> (since the notice to devel didn't happen)
17:11:56 <zbyszek> dcantrell: sounds good
17:11:58 <jmracek> Hey, compatibility with dnf is part of the plan (It is described in proposal)
17:12:44 <sgallagh> FWIW, option 3 has my vote also
17:12:45 <mhroncok> dcantrell: ack
17:12:57 <Eighth_Doctor> Fine with me
17:13:05 <nirik> offtopic: jmracek is dnf5 going to get a --refresh option? ;)
17:13:12 <jmracek> Option 3 is winning
17:13:31 <jmracek> I don't see a reason why not.
17:13:57 <jmracek> --refresh option to implement before Fedora 39 GA
17:14:15 <nirik> cool.
17:15:00 <jmracek> I will create github issue to not forget
17:16:19 <mhroncok> Contingency deadline: Branch Fedora Linux 39 from Rawhide
17:16:35 <mhroncok> is it wise to add critical options after beta, before ga?
17:16:55 <sgallagh> Branching is before Beta
17:17:01 <mhroncok> yes
17:17:02 <jmracek> No problem
17:17:10 <mhroncok> "--refresh option to implement before Fedora 39 GA"
17:17:16 <mhroncok> thats eems rather late
17:17:20 <mhroncok> * that seems rather late
17:17:42 <sgallagh> Oh, sorry. Didn't realize that was where you were going with that.
17:18:02 <mhroncok> my bad, I shoud have provided more context
17:18:05 <bcotton> I'd say it depends. If it's adding a feature that doesn't affect behavior defined in the release criteria, it could be okay
17:18:33 <sgallagh> Let's not go crazy attempting to litigate this.
17:18:35 <bcotton> I'm not sure what side effects this specific addition would have, though
17:18:42 <sgallagh> I trust jmracek :)
17:18:46 <mhroncok> anyway, not a blocker for me, I just advice caution -- if it is shipped after beta, there is not much time to correct some behavior
17:18:47 <jmracek> Thanks
17:19:07 <mhroncok> we have a plan it seems
17:19:41 <mhroncok> let's not secretly vote now because I guess people might bring pitchforks
17:19:50 <mhroncok> but I will reveal that I plan to vote +1
17:20:01 <dcantrell> jmracek: can you post on fedora devel that the revised proposal has another week for commenting?  if you do not want to, I can post
17:20:06 <dcantrell> mhroncok: :)
17:20:33 <Eighth_Doctor> I'm fine with this, and I'll not-so-secretly vote +1
17:20:42 <zbyszek> mhroncok: who's vote are you trying to influence?
17:21:23 <jmracek> We set dealine for Fedora 39 features for 2023-8-21 - see https://github.com/rpm-software-management/dnf5/milestones
17:22:31 <mhroncok> (I have another topic before the open floor)
17:22:44 <sgallagh> I have a topic for Open Floor also
17:22:57 <jmracek> Well I can post it but next week I don't want to be arround, therefore if you have a question please ask today.
17:23:22 <Eighth_Doctor> well, feel free to topic and stuff
17:23:28 <mhroncok> I guess we don't, but the devel people might
17:24:02 <Eighth_Doctor> do we want to go to Open Floor or do we have anything else?
17:24:09 <Eighth_Doctor> because there's nothing else on the planned schedule
17:24:36 <dcantrell> Eighth_Doctor: you want to action me or someone to post?
17:25:19 <Eighth_Doctor> #action dcantrell will post to devel@ to trigger dnf/dnf5 discussion
17:25:47 <mhroncok> #topic Limiting the frame pointers thing to x86_64
17:26:15 <mhroncok> So there was this proposal to limit https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer to x86_64
17:26:18 <nirik> yeah, I was gonna bring this up too...
17:26:29 <mhroncok> And to be honest, it made a lot of sense to me
17:26:39 <mhroncok> the options combo for s390x seems to be quite arbitrary
17:27:10 <mhroncok> I don't know much about the potential problems on i686 but i don't think it's worth it to beat that arch with new things
17:27:13 <zbyszek> FWIK, the change owners don't care about s390x.
17:27:24 <davide> .hello dcavalca
17:27:25 <zodbot> davide: dcavalca 'Davide Cavalca' <davide@cavalca.name>
17:27:26 <mhroncok> exactyl a good reason not to change the flags on s390x
17:27:32 * nirik is also a bit worried about the mass rebuild. Has anyone does any premass building with frame pointers enabled? or are we going to see a lot of new failures?
17:27:38 <Eighth_Doctor> well note that frame pointers are by default on ppc64le and aarch64
17:27:39 <zbyszek> But i686 is apparently potentially important.
17:27:43 <davide> yes, as mentioned on the list, we'd be ok with dropping -mbackchain for s390x
17:27:51 <davide> I was going to put up a PR to that end tomorrow
17:27:56 <mhroncok> See e.g. https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/231#comment-126098
17:28:19 <Eighth_Doctor> I would rather not see i686 dropped unless we see significant problems in mass build
17:28:45 <mhroncok> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5EXPQL3APZZLVXE2N7BMG7EOETL5YX64/
17:28:57 <davide> nirik: at Meta we build everything internal with frame pointers and haven't seen any significant issues on x86_64 and aarch64; Daan also didn't see any issues when rebuilding a subset of the distro in copr for his benchmarks
17:29:18 <nirik> note that the mass rebuild is not a nible gazelle... we can't switch things around a bunch of times during it.
17:29:23 <mhroncok> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AZBSLQXEHGJLXHR65A5VVZXVF34XNJK4/
17:29:29 <mhroncok> > I would rather not see i686 dropped unless we see significant problems in mass build
17:29:29 <mhroncok> I woudl rather we don't use the mass rebuild to test such assumptions :/
17:29:32 <nirik> davide: ok, thats encouraging
17:29:45 <davide> for i686, I had asked in the ticket if anybody had a sense of how many / which packages might be potentially impacted, but nobody replied
17:29:46 * Eighth_Doctor grumbles that mass builds should not be so special
17:30:29 <davide> assuming it's only a small number, I would prefer to deal with the failures afterwards and opting them out of frame pointers for the arch, as I've seen done in the past for other Changes that caused minor fallout during mass rebuilds
17:30:31 <nirik> it's not that they are special technically, it's that they cause a bunch of work for maintainers... having to sort out issues, etc.
17:31:06 <mhroncok> currently we have this: https://src.fedoraproject.org/rpms/redhat-rpm-config/c/9ce7719338c434c963f1f80e98e71e5fae3d06a1?branch=rawhide
17:31:39 <mhroncok> the armv7hl thing is moot
17:31:48 <mhroncok> the x86_64 thing is desired
17:32:07 <mhroncok> there is disagreement about i686
17:32:23 <mhroncok> s390x is going to be revrted I guess
17:32:38 <mhroncok> what about aarch64 and ppc64le?
17:32:39 <nirik> there's still some question on aarch64 as well I think?
17:32:50 <davide> the Change owners definitely want this for aarch64
17:32:51 <Eighth_Doctor> aarch64 and ppc64le already do this by default
17:32:55 <mhroncok> and I have absolutely no idea bout riscv64
17:33:01 <Eighth_Doctor> they have frame pointers already
17:33:03 <DaanDeMeyer[m]> For s390x, we were planning to drop mbackchain but keep fno-omit-frame-pointer
17:33:07 <sharkcz> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/231#comment-126098 is the reply from IBM s390x toolchain team
17:33:18 <nirik> if aarch64 does this already, why are there changes to it?
17:33:19 <mhroncok> Thanks sharkcz
17:34:09 <mhroncok> nirik: my guess is the flag is moot there, but I am not sure
17:34:31 <davide> for ppc64le, my understanding is that people do use these as desktop systems too, so I suspect the desktop folks would prefer having frame pointers explicitly enabled there as well so they can rely on them for profiling
17:34:43 <davide> -fno-omit-frame-pointer ensures frame pointers are always included
17:35:18 <davide> on arches where they're the default already, it is effectively a noop, but for consistency it's IMO easier and better to have it listed
17:35:35 <dcantrell> so x86_64, ppc64le, exclude s390x, and I don't care about i686
17:35:38 <davide> so folks don't need to go over the GCC sources to remember which ones do what
17:36:10 <davide> i686 is relevant in that there's still a non-trivial amount of userspace relying on it (e.g. wine, and a bunch of the android devel stack and tooling)
17:36:45 <dcantrell> fair, but those things will continue to work if i686 were excluded from this architecture list, correct?
17:37:11 <nirik> can perhaps a copr for i686 stuff be run before mass rebuild?
17:37:23 <mhroncok> nirik++
17:37:34 <davide> they will work, but if say you want to profile a game relying on wine/winelib, or some other stack that relies on i686 userspace, not having frame pointers will hurt you
17:37:43 <mhroncok> the problem with copr of course is that hundreds of things will fail for whatever reasons
17:37:48 <DaanDeMeyer[m]> sharkcz: We're OK with following this recommendation from the s390x platform team here I think and dropping fno-omit-frame-pointer and keeping mbackchain
17:38:09 <mhroncok> I understand we would drop both for s390x
17:38:33 <zbyszek> mhroncok: sounds like we should
17:38:58 <dcantrell> davide: is that really an objective of this change proposal?  I'm inclined to say we should exclude i686 since there is disagreement and unknowns about what impact it may have.  don't rock the boat, so to speak
17:39:34 <DaanDeMeyer[m]> Ideally we'd have consistent profiling experience across architectures but we're not too attached to s390 so we're also OK with dropping the flags for s390
17:39:35 <dcantrell> davide: (I mean profiling a game using wine/winelib in the i686 environment)
17:39:57 <zbyszek> We could also leave i686 out for F38 to stagger the impact, and turn it on for F39 is things go well with the other architectures.
17:40:10 <zbyszek> *if
17:40:48 <davide> the objective of the proposal is to make profiling more useful in general, and IMO that falls in scope
17:41:04 <davide> that said, it's probably not a hill worth dying on given the amount of controversy already around this
17:41:37 <dcantrell> davide: ok, I'll give you that.  but given the unknowns and risk, I would prefer we exclude i686 for now until we have a better idea of the impact
17:41:53 <davide> I think zbyszek proposal is reasonable, and I'd personally be ok with doing i686 (and s390x if there's interest) in F39
17:42:01 <davide> daandemeyer[m]: what do you think?
17:42:19 <nirik> I'd prefer not doing i686... given "-fno-omit-frame-pointer on i686 is known to break certain packages"
17:42:21 <DaanDeMeyer[m]> Sounds good to me
17:43:06 <davide> and in the meantime, we can attempt to do a mini mass rebuild for i686 in copr to gauge impact (though I agree with mhroncok that's going to be noisy)
17:43:33 <dcantrell> more targeted tests may be more useful, even if anecdotal
17:43:34 <DaanDeMeyer[m]> It'd be nice if we could narrow down "certain packages", so I don't have to rebuild the full distro if I want to check the current situation
17:43:49 <Eighth_Doctor> how would we identify them?
17:43:59 <dcantrell> like work backwards from the "profile a game using wine/winelib"
17:44:06 <davide> yeah, as I mentioned before -- I'd asked in the ticket but got not reply, if someone knows which packages might be impacted or how to identify them, that would be useful
17:44:15 <Eighth_Doctor> I know that some Gentoo guys did a bunch of work a few years ago to enable it everywhere for i686
17:44:16 <Eighth_Doctor> and it resulted in fixes in gcc and glibc
17:44:23 <nirik> perhaps fweimer has a list...
17:44:24 <sharkcz> https://gitlab.com/fedora/packager-tools/mass-prebuild should help to identify what breaks with a flag change
17:44:26 <gotmax> You could check which i686 packages are actually in the compose
17:44:33 <Eighth_Doctor> well, with gentoo, it's a use flag thing
17:44:51 <davide> thanks sharkcz ! this looks really useful
17:45:47 <sharkcz> afaik the tools team has already used it for the "fortify" work
17:46:19 <sharkcz> it should allow any future changes better prepared
17:46:54 <davide> yeah for sure
17:47:24 <nirik> so, agreed on x86_64, ppc64le, aarch64 enable, leave i686 s390x alone for now?
17:47:44 <zbyszek> +1
17:47:46 <dcantrell> +1
17:47:59 <sgallagh> nirik: +1
17:48:02 <davide> the Change owners are ok with this proposal
17:48:06 <dcantrell> (and exclude m68k, m88k, alpha, all of mips, sparc, sparc64, 65c816, and 6502  :)
17:48:13 <Eighth_Doctor> sure I guess... +1
17:48:16 <Eighth_Doctor> lol
17:48:17 <mhroncok> nirik: +1
17:48:33 <mhroncok> riscv?
17:48:36 <sgallagh> dcantrell: In before someone mentions riscv
17:48:38 <sgallagh> DAMMIT
17:48:41 <mhroncok> haha
17:48:51 <dcantrell> haha
17:49:00 <mhroncok> note that riscv folks still build Fedora 37
17:49:04 <Eighth_Doctor> Davide Cavalca, you should talk to the Fedora RISC-V folks ;)
17:49:14 <davide> for the record, riscv is enabled in the current implementation, but the Change owners have no hardware to actually test it
17:49:15 <dcantrell> I did say "all of mips", so....
17:49:24 <mhroncok> for reasons I don't know they don't build rawhide but constantly try to keep up with an older release
17:49:30 <nirik> mhroncok: their koji hub was being migrated, they should start on f38 soon now
17:49:41 <mhroncok> so i guess the riscv folks have plenty of time to figure this out
17:49:49 <davide> I believe daandemeyer[m] confirmed by looking at the GCC sources it should work properly there though
17:50:13 <music[m]> +1, although if we are doing this on x86_64 i think it should be attempted on i686 at some point
17:50:39 <music[m]> fine with waiting on that until we understand how many packages would need to opt out, though
17:50:55 <DaanDeMeyer[m]> fno-omit-frame-pointer is defined for all architectures
17:52:39 <nirik> that doesn't mean all hardware will handle it the same tho... i686 has a fewer registers for example
17:52:44 <nirik> but anyhow...
17:52:46 <Eighth_Doctor> Need to step away for a bit, sorry
17:52:55 <mhroncok> I count +7
17:53:24 <mhroncok> I need to get something to drink, brb
17:53:57 * zbyszek thinks that every successful fesco vote calls for a glass of champagne
17:54:32 <sgallagh> zbyszek: That would just lead to a lot more frivolous votes :)
17:55:27 <decathorpe> hey, sorry, had a conflict with another meeting until now
17:55:57 <nirik> anthing more on this? or shall we move to sgallagh's item(s)?
17:57:16 <mhroncok> #agree Let's exclude i686 and s390x completely from the fomit frame pointer thing for F38 (+7,0,-0)
17:57:22 <mhroncok> for completness
17:58:27 <gotmax> pretty sure it's #agreed not #agree
17:58:33 <sgallagh> both work
17:58:40 <sgallagh> They're aliased
17:59:19 <mhroncok> and https://fedoraproject.org/wiki/FESCo_meeting_process says it is #agree
17:59:55 <gotmax> hmm, good to know :)
18:01:02 <dcantrell> I'm going to have to leave soon
18:01:07 <nirik> sgallagh: you had something?
18:01:28 <sgallagh> Yeah, just a small proposal to clarify the re-vote policy
18:01:55 <sgallagh> Proposed addition to the FESCo policies page: "FESCo may, at times, consider a request to revisit a prior decision. In this case, the request must be brought to the Fedora Devel list for at least one full week of public comment prior to the revote".
18:02:31 <nirik> I think that might be too general...
18:02:34 <mhroncok> ugh that does not seem flexible
18:02:52 <zbyszek> Yeah, that seems very inflexible.
18:02:55 <mhroncok> we don't even require a week on devel for all regular votes
18:03:14 <decathorpe> we often vote on slightly different proposals within the same meeting
18:03:16 <mhroncok> (mayeb we should)
18:03:18 <mhroncok> * (maybe we should)
18:03:22 <decathorpe> that would make this basically impossible
18:03:58 <sgallagh> Fabio Valentini: I don't think that's affected by this.
18:04:00 <mhroncok> I would be fine saying this about fedora change proposals
18:04:02 <nirik> how about making it apply to previously rejected changes only?
18:04:15 <sgallagh> That's fine with me
18:04:20 <gotmax> s/request to revisit a prior decision/request to revisit a previously rejected Change Proposal/ ?
18:04:27 <mhroncok> BTW I don't consider the votes in a meeting final until the meeting is over
18:04:49 <zbyszek> nirik: -1 also, because let's say that something comes up that means that just-approved proposal has a fatal flaw or must be delayed or amended.
18:05:00 <music[m]> Rules lawyers may argue: what does it mean to revisit a rejected change?
18:05:01 <sgallagh> I don't consider them final until they've been published to the devel list :)
18:05:10 <decathorpe> I'm not sure if a rule like that wouldn't cause more problems than it solves ... and at the very least, it would slow down decisions a lot
18:05:13 <gotmax> zbyszek: s/must/should/ ?
18:05:14 <nirik> true...
18:05:30 <zbyszek> I think it'd be much better to immediate redo the vote, than to let it hang for a week or two weeks of unnecessary discussion.
18:05:55 <music[m]> Same text? Minor changes? Totally reworked? Independent but reminds someone of a previous change? Which ones are revisiting a rejeced change?
18:05:57 <sgallagh> zbyszek: Approved proposals by definition are not "previously rejected"
18:06:41 <music[m]> I guess if they were heavily changed they would just be new proposals though…
18:06:52 <decathorpe> yeah, that's the problem. is a proposal "previously rejected" if it has changes?
18:06:59 <mhroncok> So let me craft an arbitrary situation
18:07:19 <mhroncok> a change is proposed, discussed on devel for a week, voted by fesco as rejected (+4,...)
18:07:43 <mhroncok> sudenly a single additional fesco member changes their mind
18:07:55 <sgallagh> OK, I was thinking this was a quick topic, but it's clearly not. Maybe we put it on next week's agenda and think about it for a bit in the meantime?
18:07:55 <gotmax> well, if it's rewritten, wouldn't that be a new Change that requires another comment period per the current policies anyways?
18:07:59 <mhroncok> and wants to actually vote +1, making the change approved
18:08:09 <mhroncok> what benefit does an additonal week on devel bring?
18:08:49 <nirik> time to convince them they were right the first time?
18:09:10 <decathorpe> What about; Re-announce and wait for a week if proposal is different, but skip this step if the proposal is unchanged?
18:09:33 <mhroncok> (I agree that this particular revote was surprising and for many might appear to be unfair, but I don't think it would have turned differently even if whatever)
18:10:00 <gotmax> decathorpe: the frame pointers revote was basically the same proposal
18:10:17 <gotmax> and the point of this discussion is to prevent that sort of situation AFAIU
18:10:29 <mhroncok> Fabio Valentini: technically, if the change proposal changes significantly, we already do this (e.g. dnf5 or perl mod compat dependency generator)
18:10:30 * nirik does wonder what changed the folks who changed votes
18:11:19 <music[m]> decathorpe: I don’t think that would satisfy most people who are asking for the waiting period. I think, as nirik said, they want the week to allow for additional persuasion. That’s the impression I’ve gotten from devel list posts, anyway.
18:12:15 <zbyszek> sgallagh: essentially, I think that tying this down into a strict rule will make things more complicated in the future. I would just prefer us to make a soft rule that if the proposal is significantly changed or additional week of discussion is useful.
18:12:19 <sgallagh> Not necessarily persuasion, but certainly time to make sure all stances are fairly represented.
18:12:26 <nirik> and some folks would prefer ∞ if they disagree with the votes. ;)
18:12:30 <decathorpe> honestly, in this case, most complaints about the process came from people who didn't like the outcome, so I'm not sure if any chanhes to the process would make them happy 🤷🏻‍♂️
18:12:36 <zbyszek> ... we will delay voting for a week or two.
18:13:25 <nirik> I'd say the appearence here was not great due to the meeting during the holidays...
18:13:28 <zbyszek> decathorpe: exactly my feeling
18:13:56 <nirik> but to avoid that we can just make sure not to meet in early jan moving forward.
18:14:23 <bcotton> i think requiring resubmission after a vote to reject make sense
18:15:13 <bcotton> and also for "significant" changes, but that gets into a gray area that i'm not sure we can legislate to anyone's satisfaction
18:15:47 <bcotton> but once a proposal is rejected, it should go through the process again (i would not, as some have proposed, forbid it to be re-submitted for the same release)
18:16:04 <zbyszek> bcotton: but what would that achieve?
18:16:17 <bcotton> visibility
18:16:34 <nirik> in most cases where something was rejected I would expect the change to be reworked/changed. This case was not typical.
18:16:45 <zbyszek> But it was extremely visible already. All the people who's votes formally count were aware of it.
18:16:49 <music[m]> sgallagh: I would argue that, for an unchanged proposal, that time was already available. But I guess the counterargument would be that a re-vote without the full announcement and delay allows one side of the debate to get in the “last word” without the opposition having a chance to counter.
18:17:25 <bcotton> "all the people whose votes formally count" isn't a great way to run a community project, though
18:18:25 <bcotton> requiring a full re-submission of a rejected proposal is one of those cases where doing the slow and arguably silly thing is better for the long term health of the community
18:19:04 <mhroncok> What Ben Cotton (he/him) says makes sense
18:19:13 <mhroncok> the additional week would not have changed the outcome
18:19:23 <davide> my feeling is that part of the controversy here boils down to people not feeling they're being heard; would it make sense for FESCo to formally request folks involved in a proposal discussion to join the meeting?
18:19:24 <mhroncok> but it would change the perception
18:19:31 <davide> of course defining "involved" might be tricky
18:19:42 <sgallagh> Davide Cavalca: They're already always invited.
18:19:48 <mhroncok> Davide Cavalca: not in this case IMHO
18:19:48 <nirik> well, they are welcome to join already?
18:19:51 <sgallagh> But they do not (or cannot) always attend
18:20:11 <mhroncok> Stephen Gallagher: I don't think they are always *explicitly* invited
18:20:20 <nirik> I think all the data/positions were known... it wasn't a matter of not listening. I read every post/ticket at least
18:20:22 <davide> I mean, everyone can join, I was more thinking sending them an email specifically, or CC'ing on the schedule email that goes to devel, or.... something
18:20:35 <mhroncok> welcome to join but had no idea about this happening
18:20:49 <davide> I don't think people normally think of joining this meeting unless they think they'll have something to say
18:21:02 <zbyszek> Yeah, we should probably CC them. But we also have a published agenda.
18:21:10 <sgallagh> https://www.goodreads.com/quotes/40705-but-the-plans-were-on-display-on-display-i-eventually
18:21:17 <mhroncok> "I think all the data/positions were known" -- this is the reason why I assumed it is OK to just proceed with the vote
18:21:48 <mhroncok> in restrospect, I think that was a bad call
18:21:53 <mhroncok> s/restrospect/retrospect/
18:22:16 <gotmax> well, the other side wasn't able to respond to the new circumstances/reasoning that prompted the new vote
18:22:24 <bcotton> sgallagh++
18:22:41 <nirik> gotmax: was their any new data?
18:22:46 <gotmax> and only the proponents were aware of the new ticket
18:22:55 <bcotton> nirik: i have no idea how you keep up with everything. but you hearing isn't the same as people feeling heard
18:23:00 <mhroncok> BTW I fundamentally disagree with what Kevin K. said -- that postponing the vote would be good because it would push this change to f39
18:23:21 <mhroncok> but I think that postponing it would have been a good thing for transparency
18:23:30 <gotmax> nirik: well, what convinced the FESCo members?
18:23:35 <gotmax> it didn't come out of the blue
18:23:45 <nirik> bcotton: true. Perhaps I (and also all fesco) could be better about replying to the list and saying what their thoughts are and that they heard argument X, but it wasn't compelling because Y
18:24:02 <nirik> gotmax: I am not sure. I voted -1 in the end. ;)
18:24:26 <zbyszek> nirik: such replies were made. The discussion was going in circles.
18:24:31 <gotmax> <gotmax> it didn't come out of the blue | bad choice of words. I meant there's something that prompted the re-vote
18:24:59 <bcotton> ultimately, i'm not sure there's anything that could have avoided a big blow up on devel in this particular case. but erring on the side of transparency seems like the right general position to take
18:25:03 <gotmax> whether that's new information, new logic, or new justification
18:25:53 <gotmax> some of the thread was just railing against the situation in a rude way, but there were people who respectfully raised legitimate concerns with the process
18:27:36 <gotmax> what would be the harm of delaying to F39 to give the change more time to incubate in rawhide instead of doing something so late in the cycle that could cause problems in the mass rebuild?
18:28:06 <zbyszek> gotmax: That applies to pretty much every change. The proposal was made 6 months ago.
18:28:08 <gotmax> I think that's a reasonable middle ground that would assuage some concerns
18:28:36 <zbyszek> It'd just delay things without materially changing anything, because we'll get proper feedback only during the mass rebuild.
18:28:51 <zbyszek> (Or after.)
18:29:08 <gotmax> zbyszek: sure it was proposed then, but it didn't actually land until now
18:29:29 <gotmax> and there's remaining questions about architecture differences
18:29:39 <decathorpe> architectures that would be most affected by this change aren't covered by koschei. so only a mass rebuild will surface some breakage ...
18:30:16 <zbyszek> gotmax: the finer points about architecture differences were raised *because* the change landed and people started looking more carefully at the implementation.
18:30:47 <mhroncok> we ar eon this for a long time
18:30:49 <zbyszek> If we let the change sit in a PR, most likely there would have been much less feedback.
18:30:51 <mhroncok> s/ar/are/, s/eon/on/
18:31:01 <mhroncok> I don't feel like this meeting is very productive at this point
18:31:12 <mhroncok> let's think about it and talk about it next week?
18:31:16 <zbyszek> This is how things generally happen in Fedora, most people are too busy to look at proposals.
18:31:42 <gotmax> now that those questions were raised, it'd be good to have time to answer those before actually implementing the change
18:33:06 <gotmax> the mass rebuilds are already chaotic enough and this hasn't had any time to be tested in the distribution when the stakes are lower
18:33:55 <zbyszek> gotmax: I agree that it would have been nicer if the whole thing was processed earlier. We can try to do better in the future.
18:34:34 <zbyszek> But I don't think that this can be codified in a meaningful way without making the whole processes slower and harder.
18:35:06 <gotmax> rushing the change in like this feels bad to me and makes the optics of this worse
18:35:43 <gotmax> I'm not saying we should add more procedural hurdles to all changes
18:35:55 <bcotton> mhroncok: if you (the collective "you") would like, you (the individual "you") can #action bcotton to make a proposal on the mailing list to explicitly require full resubmission of rejected proposals (and then bring it to a FESCo ticket once discussion has happened)
18:36:22 <sgallagh> Sounds reasonable, Ben
18:36:31 <nirik> gotmax: I'd be fine with postponing it, but I don't think there's enough votes for that...
18:36:36 <mhroncok> #action bcotton to make a proposal on the mailing list to explicitly require full resubmission of rejected proposals (and then bring it to a FESCo ticket once discussion has happened)
18:36:41 <bcotton> that's twice in this meeting that i've made sense. i'm getting concerned
18:36:47 <mhroncok> assuming the collective us want that
18:36:57 <gotmax> but I think having a SHOULD policy about not doing votes over holidays or having comment periods for a reconsidered changes would be a good idea
18:37:22 <mhroncok> the holidays thing is a different problem
18:37:23 <music[m]> (whose holidays?)
18:37:35 <mhroncok> everybody assumes the time has stopped, but the schedule is still ticking
18:37:56 <bcotton> and some people contribute more to Fedora when they're off work
18:37:59 <decathorpe> but mass rebuild after Christmas is always tight. this isn't the first time
18:38:00 <gotmax> there could be a clause about FESCo having discretion about what's considered a previously rejected change
18:38:15 <mhroncok> and for some, 3rd of January is too soon
18:38:39 <zbyszek> 7th of January is x-mas for a large part of Europe.
18:38:39 <mhroncok> for others, maybe the entire November to January period is off limits :/
18:38:41 * sgallagh regrets bringing this up.
18:38:56 * decathorpe regrets being here ;)
18:39:02 <gotmax> several others brought it up on the mailing list first
18:39:19 * nirik regrets that his coffee cup is empty
18:39:31 <mhroncok> I propose we proceed with next's weeks chair
18:39:33 <gotmax> someone should create a FESCo ticket (I could) about considering policy changes to prevent this type of situation in the future
18:39:45 <nirik> mhroncok: +1
18:39:46 * dtometzki 7th x-mas mmmhhh
18:39:50 <mhroncok> gotmax: I've actioned Ben
18:39:53 <bcotton> gotmax: see the #action bcotton above
18:39:55 <gotmax> it caused a lot of strife and distrust which is harmful for the community
18:40:15 <decathorpe> I think that's more productive than this meeting yeah
18:40:24 <gotmax> ah, I missed that
18:40:35 <gotmax> sorry...
18:40:53 <mhroncok> it's fine
18:40:54 <mhroncok> this is on us
18:41:14 <mhroncok> anything else for open floor?
18:41:17 <mhroncok> (please no)
18:42:04 <sgallagh> I think we're done
18:42:07 <mhroncok> I read that as a no
18:42:22 <decathorpe> my cell service will drop out soon so no
18:42:23 <mhroncok> #topic Next week's chair
18:42:31 <mhroncok> volunteers?
18:42:49 <zbyszek> I can do it.
18:42:55 <mhroncok> thanks
18:43:10 <mhroncok> #action zbyszek will chair next meeting
18:43:17 <mhroncok> #endmeeting