2024-10-08 17:01:33 <@zbyszek:fedora.im> !startmeeting FESCO (2024-10-08)

2024-10-08 17:01:34 <@meetbot:fedora.im> Meeting started at 2024-10-08 17:01:33 UTC
2024-10-08 17:01:34 <@meetbot:fedora.im> The Meeting name is 'FESCO (2024-10-08)'
2024-10-08 17:01:39 <@zbyszek:fedora.im> Chairs: @conan_kudo:matrix.org, @ngompa:fedora.im, @nirik:matrix.scrye.com, @humaton:fedora.im, @zbyszek:fedora.im, @sgallagh:fedora.im, @jistone:fedora.im, @dcantrell:fedora.im, @decathorpe:fedora.im, @salimma:fedora.im
2024-10-08 17:01:39 <@zbyszek:fedora.im> !meetingname fesco
2024-10-08 17:01:40 <@meetbot:fedora.im> The Meeting Name is now fesco
2024-10-08 17:01:47 <@zbyszek:fedora.im> !topic Init Process
2024-10-08 17:01:52 <@jistone:fedora.im> !hi
2024-10-08 17:01:53 <@zodbot:fedora.im> Josh Stone (jistone) - he / him / his
2024-10-08 17:02:01 <@zbyszek:fedora.im> !hi
2024-10-08 17:02:02 <@zodbot:fedora.im> Zbigniew Jędrzejewski-Szmek (zbyszek)
2024-10-08 17:02:04 <@dcantrell:fedora.im> !hi
2024-10-08 17:02:05 <@zodbot:fedora.im> David Cantrell (dcantrell) - he / him / his
2024-10-08 17:02:17 <@nirik:matrix.scrye.com> morning
2024-10-08 17:02:36 <@zbyszek:fedora.im> Neal said that he might not make it.
2024-10-08 17:03:03 <@zbyszek:fedora.im> We're four. Let's wait a bit more.
2024-10-08 17:03:07 <@sgallagh:fedora.im> !hi
2024-10-08 17:03:08 <@zodbot:fedora.im> Stephen Gallagher (sgallagh) - he / him / his
2024-10-08 17:03:14 <@zbyszek:fedora.im> Now five.
2024-10-08 17:03:28 <@zbyszek:fedora.im> !fesco 3271
2024-10-08 17:03:28 <@zbyszek:fedora.im> !topic #3271 [F41 blocker] Ensure that all packages with dead.package are removed from repos
2024-10-08 17:03:42 <@zbyszek:fedora.im> Should we just close this?
2024-10-08 17:03:53 <@nirik:matrix.scrye.com> +1 to just close
2024-10-08 17:03:58 <@dcantrell:fedora.im> +1 to close
2024-10-08 17:04:02 <@jistone:fedora.im> +1
2024-10-08 17:04:07 <@zbyszek:fedora.im> +1
2024-10-08 17:04:20 <@zbyszek:fedora.im> !fesco 3271
2024-10-08 17:04:21 <@zodbot:fedora.im> ● **Opened:** 3 weeks ago by gotmax23
2024-10-08 17:04:21 <@zodbot:fedora.im> ● **Assignee:** Not Assigned
2024-10-08 17:04:21 <@zodbot:fedora.im> ● **Last Updated:** a week ago
2024-10-08 17:04:21 <@zodbot:fedora.im> 
2024-10-08 17:04:21 <@zodbot:fedora.im> **fesco #3271** (https://pagure.io/fesco/issue/3271):**[F41 blocker] Ensure that all packages with dead.package are removed from repos**
2024-10-08 17:04:34 <@zbyszek:fedora.im> I have no idea why it didn't work the first time.
2024-10-08 17:04:56 <@zbyszek:fedora.im> Stephen Gallagher: vote?
2024-10-08 17:05:00 <@jistone:fedora.im> was it lumped in with the `!topic`?
2024-10-08 17:05:14 <@zbyszek:fedora.im> Yeah, but this was supposed to be fixed to work.
2024-10-08 17:05:22 <@sgallagh:fedora.im> +1
2024-10-08 17:05:40 <@zbyszek:fedora.im> !agree Just close the ticket (+5, 0, 0)
2024-10-08 17:05:46 <@zbyszek:fedora.im> !topic #3272 Change: Anaconda Web UI partitioning
2024-10-08 17:05:50 <@zbyszek:fedora.im> !topic 3272
2024-10-08 17:06:35 <@zbyszek:fedora.im> !topic #3272 Change: Anaconda Web UI partitioning
2024-10-08 17:06:38 <@zbyszek:fedora.im> !fesco 3272
2024-10-08 17:06:39 <@zodbot:fedora.im> 
2024-10-08 17:06:39 <@zodbot:fedora.im> **fesco #3272** (https://pagure.io/fesco/issue/3272):**Change: Anaconda Web UI partitioning**
2024-10-08 17:06:39 <@zodbot:fedora.im> ● **Assignee:** jkonecny
2024-10-08 17:06:39 <@zodbot:fedora.im> ● **Last Updated:** 2 hours ago
2024-10-08 17:06:39 <@zodbot:fedora.im> ● **Opened:** 2 weeks ago by amoloney
2024-10-08 17:06:41 <@zbyszek:fedora.im> Sorry.
2024-10-08 17:07:03 <@nirik:matrix.scrye.com> so, perhaps we should just pause this until things are more implemented?
2024-10-08 17:07:12 <@nirik:matrix.scrye.com> (but before the deadline to submit)
2024-10-08 17:07:13 <@jistone:fedora.im> I haven't tried the new UI, but this is quite a risky area to not be sure about
2024-10-08 17:07:41 <@sgallagh:fedora.im> I'm not sure it's fair to the developers to keep stringing them along forever. I'm also not sure what happens if we say "no".
2024-10-08 17:08:09 <@sgallagh:fedora.im> They've been quite clear about not having the resources to continue *developing* both installers.
2024-10-08 17:08:33 <@sgallagh:fedora.im> Fedora can probably coast on RHEL 10's maintenance of the existing UI for a few years, but that's not necessarily a good long-term strategy
2024-10-08 17:08:55 <@zbyszek:fedora.im> I expect that the answer will be "yes, let's pause". But I don't think this is a terribly good answer. The developers ask us to provide some guidance, and delaying on this is not very helpful. But OTOH, when guidance/opinions were provided, I don't think they were really heard.
2024-10-08 17:09:12 <@zbyszek:fedora.im> The situation is hard, there is no easy answer here.
2024-10-08 17:09:27 <@sgallagh:fedora.im> zbyszek: I disagree with that last sentence. I provided some feedback that was incorporated immediately.
2024-10-08 17:09:32 <@zbyszek:fedora.im> But I very much have the feeling that we're moving in a wrong direction with the development of the installer.
2024-10-08 17:09:34 <@nirik:matrix.scrye.com> well, sure, guidence should be given / understood. Perhaps we could invite them here? or have some kind of video meeting ?
2024-10-08 17:09:48 <@dcantrell:fedora.im> Having spent a very long time on the installer team, anaconda has the unfortunate job of serving multiple orthogonal users.  RHEL rules the show in terms of what gets resource priority.  FESCo can't really stop their work, but we also shouldn't.  I think we should probably let this change go through, but ask for a spin or variant that we can use in Fedora as a fallback which uses the existing UI
2024-10-08 17:10:12 <@dcantrell:fedora.im> I also have a hard time being objective on this because the part of the installer they want to remove is the part I worked on for a VERY LONG time
2024-10-08 17:11:37 <@sgallagh:fedora.im> dcantrell: The "NewUI" in general, or the "queue-then-execute" logic that seems to be the sticking point?
2024-10-08 17:11:40 <@nirik:matrix.scrye.com> or I suppose guidence could have more weight if we drafted up a list and all approved it as fesco instead of each one of us... but not sure if that will magically give them the time/resources to make all those changes.
2024-10-08 17:11:40 <@zbyszek:fedora.im> Hmm, I think this would be quite problematic. We'd have an unmaintained "old" installer somewhere on the side, and a new "official" installer that people would use that would be a regression feature-wise.
2024-10-08 17:11:40 <@zbyszek:fedora.im> 
2024-10-08 17:11:40 <@zbyszek:fedora.im> > I think we should probably let this change go through, but ask for a spin or variant that we can use in Fedora as a fallback which uses the existing UI
2024-10-08 17:12:15 <@humaton:fedora.im> !hi
2024-10-08 17:12:16 <@dcantrell:fedora.im> both
2024-10-08 17:12:17 <@zodbot:fedora.im> Tomáš Hrčka (humaton) - he / him / his
2024-10-08 17:12:19 <@humaton:fedora.im> sorry I am late
2024-10-08 17:12:23 <@sgallagh:fedora.im> Can I propose that we at least take a quick vote on whether "queue-then-execute" is a blocking issue for FESCo?
2024-10-08 17:12:48 <@sgallagh:fedora.im> Because if the answer to that is "yes", then moving forward is impossible without a major redesign, and therefore we have to vote no on the change
2024-10-08 17:13:00 <@dcantrell:fedora.im> yeah, it's not ideal but one thing we failed to do way back when was provide a known-working-installer as we worked through the installer rewrite.  we recognized that after the fact
2024-10-08 17:13:01 <@nirik:matrix.scrye.com> well, can we refresh my memory at least for what flow/context that is in?
2024-10-08 17:13:35 <@sgallagh:fedora.im> nirik: Custom partitioning flow
2024-10-08 17:14:09 <@jistone:fedora.im> and the new one does it incrementally instead?
2024-10-08 17:14:14 <@dcantrell:fedora.im> the proposal now applies changes as you make them rather than queuing up all of the destructive actions
2024-10-08 17:14:23 <@zbyszek:fedora.im> For me, it is.
2024-10-08 17:14:30 <@sgallagh:fedora.im> Josh Stone: Correct, changes in the custom partitioning UI will apply as you go.
2024-10-08 17:14:32 <@dcantrell:fedora.im> fwiw, that's what original anaconda did and we changed it to queue up actions
2024-10-08 17:14:47 <@dcantrell:fedora.im> now the plan is to go back to the apply as you go model
2024-10-08 17:15:00 <@zbyszek:fedora.im> Removing that feature is just a giant step backwards.
2024-10-08 17:15:38 <@sgallagh:fedora.im> I don't think anyone (here) disagrees that it's a regression. The question I asked was "is it a big enough regression to BLOCK on?"
2024-10-08 17:15:41 <@nirik:matrix.scrye.com> sure, but they didn't remove it, they moved to a new setup that doesn't support it. I know it's the same in the end, but 'removing it' sounds like they are deliberately removing it
2024-10-08 17:16:39 <@dcantrell:fedora.im> I would say they are removing it by way of another deliberate decision
2024-10-08 17:16:39 <@zbyszek:fedora.im> For us, it's a removal. We are not really dictating how the installer works internally. What matters is what types of layouts you can install and how the workflow looks.
2024-10-08 17:17:30 <@dcantrell:fedora.im> when we moved anaconda to the queuing model, we eliminated entire classes of installation bugs from fedora.  yes, it was a bumpy ride to get there, but I do forsee a lot of those coming back
2024-10-08 17:17:59 <@sgallagh:fedora.im> dcantrell: FWIW, when I spoke with jstanek, it didn't sound like they *want* to regress this, but the only reasonably-complete API they have to work via Cockpit/WebUI with doesn't support it.
2024-10-08 17:18:37 <@dcantrell:fedora.im> that's fine, but I think the way anaconda does things now is important enough that it should require an API that supports that functionality
2024-10-08 17:19:08 <@sgallagh:fedora.im> This is why what I asked for from them as a counter-proposal was for them to make the well-tested "guided partitioning" path more robust, with more (vetted) options
2024-10-08 17:20:02 <@sgallagh:fedora.im> I'm personally willing to accept that the fully-custom partitioning path is a "here be dragons!" approach.
2024-10-08 17:20:12 <@zbyszek:fedora.im> They are very strongly attached to the idea of using Cockpit. But in my experiments with this, that backend doesn't seem ready to be used in an installer. Apart from immediate execution, the amount of information that was displayed about the layout on disk wasn't nearly enough to understand even what is currently installed. So it seems to me that it'll be quite long before WebUI is actually pleasant to use.
2024-10-08 17:20:52 <@sgallagh:fedora.im> If you click in there, you should know what you are doing. That's *IF* the guided path is reasonably sensible and offers a choice of reasonable offerings that would apply to most consumers.
2024-10-08 17:20:59 <@dcantrell:fedora.im> you can't handle every user's scenario, but you can make sure the paths we can handle are reliable and well supported.  and for the special cases, we gain enough to explain to the user that they are in uncharted waters
2024-10-08 17:21:20 <@sgallagh:fedora.im> dcantrell: Better phrased than mine, but pretty much what I'm saying.
2024-10-08 17:22:06 <@humaton:fedora.im> I agree with Stephen Gallagher , and we should embrace new development efforts. 
2024-10-08 17:22:12 <@zbyszek:fedora.im> Yeah. "Guided partitioning" is a good idea. But it also requires "queue-and-execute". Because apart from the trivial case of "nuke everything and install to full disk", the user will want to _preview_.
2024-10-08 17:23:05 <@humaton:fedora.im> Ok there will be few releases we will get feedback from angry users because they vent into the dragon land and broke storage. But we should not stay on version on anaconda that is not moving forward.
2024-10-08 17:23:19 <@zbyszek:fedora.im> E.g. if I select "install alongside existing partition", before I click "OK", I really want to have a description of what will happen. Is my /home partition on the list of things to spare? 
2024-10-08 17:23:33 <@sgallagh:fedora.im> A preview can possibly be simulated/estimated without having the APIs in place to do it "for real".
2024-10-08 17:24:12 <@dcantrell:fedora.im> that was why blivet was written.  it models storage changes without having to be destructive and lets the installer display the proposal
2024-10-08 17:24:12 <@jistone:fedora.im> Have they talked to Cockpit about adding queue-and-execute APIs here? (I don't see any issues at a glance)
2024-10-08 17:24:56 <@sgallagh:fedora.im> Josh Stone: It's `storaged` I think, Cockpit just consumes it
2024-10-08 17:25:01 <@zbyszek:fedora.im> How would that even work? You need to make a list of things to remove and a list of things to add and display that in some reasonable fashion. That is exactly queue-and-execute.
2024-10-08 17:25:05 <@sgallagh:fedora.im> Josh Stone: It's `storaged` I think. Cockpit just consumes it
2024-10-08 17:26:23 <@sgallagh:fedora.im> zbyszek: I'm not going to debate possible implementations (especially since I won't be developing them). It would be enough to say "The installer thinks you want to keep this partition around as /home, is that correct?" without knowing drive geometry
2024-10-08 17:26:48 <@dcantrell:fedora.im> that's what the blivet python module in anaconda does
2024-10-08 17:27:07 <@dcantrell:fedora.im> drive geometries don't matter in 2024
2024-10-08 17:27:50 <@jistone:fedora.im> blivet is also part of storaged-project, right? so what's the missing link?
2024-10-08 17:28:21 <@dcantrell:fedora.im> I believe so.  It began life in anaconda and was split out as a separate project.
2024-10-08 17:29:15 <@jistone:fedora.im> I mean, we shouldn't get too deep into specifics, but I (naively) don't see why this *can't* be done
2024-10-08 17:29:52 <@zbyszek:fedora.im> So this is an interesting comment. I think coasting for while might be the right approach here.
2024-10-08 17:33:01 <@nirik:matrix.scrye.com> If we do decide to do that... we should be clear in what they need to do to get webui in... just queue-and-execute?
2024-10-08 17:33:58 <@sgallagh:fedora.im> Do we necessarily need to dictate queue-and-execute, or can we dictate instead that we need a confirmation screen prior to changes on the disk that indicates what partitions may be affected destructively?
2024-10-08 17:34:18 <@sgallagh:fedora.im> The implementation may indeed require queue-then-execute, but I'm not ruling out clever tricks.
2024-10-08 17:34:40 <@sgallagh:fedora.im> Do we necessarily need to dictate queue-then-execute, or can we dictate instead that we need a confirmation screen prior to changes on the disk that indicates what partitions may be affected destructively?
2024-10-08 17:34:56 <@dcantrell:fedora.im> I like the require confirmation/review rather than dictating queue-and-execute specifically
2024-10-08 17:35:05 <@zbyszek:fedora.im> By "confirmation screen" do you mean a screen that shows in detail what would be done, or just a click-through dialogue?
2024-10-08 17:35:33 <@sgallagh:fedora.im> zbyszek: I'm setting a minimum requirement of "the following partitions may be removed or resized:"
2024-10-08 17:37:14 <@sgallagh:fedora.im> "removed, reformatted or resized" maybe
2024-10-08 17:37:30 <@sgallagh:fedora.im> But the requirement to identify them would be key
2024-10-08 17:37:43 <@dcantrell:fedora.im> the most important thing is to warn the user of any potential data loss that installation may cause
2024-10-08 17:39:05 <@zbyszek:fedora.im> That seems a bit strange way to phrase this. Removal and reformatting mean data loss, but resizing presumably doesn't.
2024-10-08 17:39:52 <@sgallagh:fedora.im> zbyszek: It *shouldn't*, but I've had bad experiences resizing e.g. ntfs before
2024-10-08 17:40:28 <@jistone:fedora.im> IIRC gparted calls out those kinds of issues
2024-10-08 17:40:51 <@zbyszek:fedora.im> We probably shouldn't be discussing those details here. Maybe we can just say that a list of operations that is planned it the followign?
2024-10-08 17:41:06 <@zbyszek:fedora.im> We probably shouldn't be discussing those details here. Maybe we can just say that a list of operations that is planned is the following?
2024-10-08 17:41:27 <@sgallagh:fedora.im> As long as our (FESCo) requirement is just that there's a confirmation that includes an identified list of partitions that might be affected in a way that MAY lead to data-loss on them, I'll be happy.
2024-10-08 17:41:49 <@zbyszek:fedora.im> I don't think that's enough.
2024-10-08 17:41:52 <@nirik:matrix.scrye.com> I think it was discussed a lot last time this change was discussed... I think they said they couldn't do that... but I don't recall all the details
2024-10-08 17:42:23 <@zbyszek:fedora.im> In principle _anything_ can lead to data loss. 
2024-10-08 17:42:30 <@sgallagh:fedora.im> As I said; the actual implementation might mean they have to do the full "queue-then-execute", but I'm leaving it open enough for them to find another path
2024-10-08 17:43:15 <@sgallagh:fedora.im> zbyszek: Fine, "has a statistically significant chance of causing data loss". Better?
2024-10-08 17:44:00 <@sgallagh:fedora.im> (I probably could have just said "nontrivial", but meh)
2024-10-08 17:44:53 <@jistone:fedora.im> remove and reformat are buggy if they *don't* cause data loss ;)
2024-10-08 17:45:33 <@zbyszek:fedora.im> Not really :(. I think we're after different goals. I want to have a _preview_ of what will happen, i.e. a list of operations that allow a semi-advanced user to see what happens. What you are talking about sounds a lot like just having a windows-style dialogue that's mostly about pushing away responsibility.
2024-10-08 17:47:04 <@zbyszek:fedora.im> In particular, the pattern I have seen so far is that when people complain about something, next iteration of Anaconda just makes the feature less visible. E.g. there we complaints about immediate execution, and this resulted in a a big fat warning being added, and the advanced partitioning being hidden in s drop-down menu. This wasn't an improvement.
2024-10-08 17:47:16 <@sgallagh:fedora.im> zbyszek: I also want what you want. It doesn't sound like we'll necessarily get the ideal outcome, so I'm trying to find a middle-ground where we could at least move ahead.
2024-10-08 17:47:30 <@zbyszek:fedora.im> So I think that if we ask for "a confirmation that includes an identified list of partitions that might be affected", we'll get exactly that.
2024-10-08 17:48:22 <@dcantrell:fedora.im> I think it's important to ask for a single point of review/confirmation of what will happen.  I don't want to have lots of warning dialogs pop up and it execute changes as I go through the UI
2024-10-08 17:49:00 <@zbyszek:fedora.im> > we decided to choose another approach, which we are calling guided partitioning. This type of partitioning is giving users paths with explanations of what will happen but does not overload them with too many options at once. These paths could be then customized.
2024-10-08 17:49:00 <@zbyszek:fedora.im> But so far the WebUI installer doesn't provide customization.
2024-10-08 17:49:00 <@zbyszek:fedora.im> In the change page, I see this:
2024-10-08 17:49:00 <@zbyszek:fedora.im> 
2024-10-08 17:49:04 <@dcantrell:fedora.im> also, I have a meeting coming up in about 10 minutes
2024-10-08 17:50:42 <@zbyszek:fedora.im> I think we've learned that this is not a good approach. Our goal is to _constantly_ grow the user base. No data loss, no broken installs.
2024-10-08 17:51:22 <@sgallagh:fedora.im> OK, can we at least take a vote on the following?
2024-10-08 17:51:22 <@sgallagh:fedora.im> Proposal: FESCo considers it a requirement that the new installer includes a full preview of all partitioning changes prior to their application, regardless of the partitioning flow.
2024-10-08 17:51:22 <@sgallagh:fedora.im> 
2024-10-08 17:51:22 <@sgallagh:fedora.im> 
2024-10-08 17:51:22 <@sgallagh:fedora.im> I'm -1 on this, but we need to at least figure out where we stand.
2024-10-08 17:51:46 <@zbyszek:fedora.im> +1
2024-10-08 17:51:50 <@humaton:fedora.im> -1
2024-10-08 17:51:54 <@dcantrell:fedora.im> +1
2024-10-08 17:53:21 <@jistone:fedora.im> +1, though I might rephrase it as "strong preference" -- I'd be willing to look at alternatives
2024-10-08 17:53:28 <@nirik:matrix.scrye.com> weak -1 I guess. I can see flows that might not need this.
2024-10-08 17:53:53 <@nirik:matrix.scrye.com> (but also, if this is a requirement, why didn't we tell them a year ago? I guess we didn't know all the way back then?)
2024-10-08 17:53:56 <@zbyszek:fedora.im> +3, 0, -3, nice and even :)
2024-10-08 17:54:58 <@sgallagh:fedora.im> nirik: We did, and they've been telling us they don't have the ability/resources to do it.
2024-10-08 17:57:40 <@nirik:matrix.scrye.com> it's a bad situation... I am not sure what the best way out of it is. ;(
2024-10-08 17:57:44 <@zbyszek:fedora.im> That'd mean that people have to commit work before knowing that it'll be accepted in Fedora. I think that's better than to set fake expectations.
2024-10-08 17:57:44 <@zbyszek:fedora.im> 
2024-10-08 17:57:44 <@zbyszek:fedora.im> I'm leaning more and more towards the opinion that we shouldn't commit to accepting any kind of new technology before it can be evaluated. No matter if it's the installer, or some web server or DNS software or complier. Promises and plans are not enough. Things must have a functionally complete preview before we accept a Change for Fedora.
2024-10-08 17:58:04 <@zbyszek:fedora.im> That'd mean that people have to commit work before knowing that it'll be accepted in Fedora. I think that's better than to set fake expectations.
2024-10-08 17:58:04 <@zbyszek:fedora.im> 
2024-10-08 17:58:04 <@zbyszek:fedora.im> I'm leaning more and more towards the opinion that we shouldn't commit to accepting any kind of new technology before it can be evaluated. No matter if it's the installer, or some web server or DNS software or compiler. Promises and plans are not enough. Things must have a functionally complete preview before we accept a Change for Fedora.
2024-10-08 17:58:54 <@nirik:matrix.scrye.com> well, the idea is that we accept the plan and if they don't meet it we take the contingency
2024-10-08 17:58:55 <@sgallagh:fedora.im> zbyszek: That would lead to other distros becoming the "developer" distro. That's not good either.
2024-10-08 17:59:11 <@jistone:fedora.im> I think we could go that route, but then we'll also need some RFC-like process for agreeing that something is worth working on in the first place
2024-10-08 17:59:45 <@sgallagh:fedora.im> zbyszek: Also, I'm pretty sure systemd would not have landed in Fedora until at least F33 in that case ;-)
2024-10-08 17:59:57 <@dcantrell:fedora.im> yep
2024-10-08 18:01:42 <@zbyszek:fedora.im> Consider the pipewire switch. The new tool was available for a few releases as an option. We delayed the switch to it as the default until it was at feature parity. We didn't buy a cat in a bag.
2024-10-08 18:02:23 <@zbyszek:fedora.im> Fedora would/could still be a developer distro. But it shouldn't be a testing ground for half-written software.
2024-10-08 18:02:41 <@sgallagh:fedora.im> We've been on this topic for about an hour and (based on that proposal above), we are thoroughly deadlocked. So what next?
2024-10-08 18:02:46 <@zbyszek:fedora.im> (In the default path. Having experimental things to opt-in is fine.)
2024-10-08 18:03:09 <@dcantrell:fedora.im> I think we should vote it down and let that decision light a fire under the RHEL powers that be
2024-10-08 18:03:55 <@nirik:matrix.scrye.com> punt and perhaps ask anaconda folks to come to the next meeting?
2024-10-08 18:05:18 <@jistone:fedora.im> the change owners didn't seem to think we should be voting at all yet, but they'd like guidance -- we can reiterate that queuing would sway minds here
2024-10-08 18:05:21 <@sgallagh:fedora.im> dcantrell: Voting it down without having agreed-upon feedback on what they need to change seems kind of tacky to me.
2024-10-08 18:05:41 <@zbyszek:fedora.im> People love pointing out the early adoption of systemd. The irony is not lost on me. But I also think that we've learned and Fedora is in a different place now and that we should do things better.
2024-10-08 18:05:44 <@sgallagh:fedora.im> That as well; they asked that we offer feedback and defer the vote a few weeks
2024-10-08 18:06:19 <@sgallagh:fedora.im> zbyszek: Sorry, that was perhaps a bit rude of me.
2024-10-08 18:08:39 <@zbyszek:fedora.im> FESCo also rejected my proposal to update systemd versions in stable releases… I think that was a reasonable decision.
2024-10-08 18:09:09 <@zbyszek:fedora.im> I hope that one day it's more stable… But until then, FESCo should push back.
2024-10-08 18:09:48 <@zbyszek:fedora.im> OK, let's wrap this up somehow.
2024-10-08 18:10:32 <@conan_kudo:matrix.org> !hi
2024-10-08 18:10:34 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2024-10-08 18:11:24 <@zbyszek:fedora.im> OK, I'll reach out to Anaconda folks to ask when they could join the meeting. Let's punt until then.
2024-10-08 18:11:38 <@zbyszek:fedora.im> !topic Next week's chair
2024-10-08 18:11:45 <@zbyszek:fedora.im> Volunteers?
2024-10-08 18:12:36 <@zbyszek:fedora.im> OK, I can do next week. I'll be travelling after that, so somebody else will have to step up.
2024-10-08 18:12:43 <@zbyszek:fedora.im> !action zbyszek will chair the next meeting
2024-10-08 18:12:49 <@zbyszek:fedora.im> !topic Open Floor
2024-10-08 18:13:07 <@sgallagh:fedora.im> I can do next week
2024-10-08 18:13:18 <@sgallagh:fedora.im> (Sorry, someone was at the door)
2024-10-08 18:13:30 <@zbyszek:fedora.im> !action Stephen will chair the next meeting.
2024-10-08 18:13:36 <@zbyszek:fedora.im> (I don't think !undo works.)
2024-10-08 18:13:39 <@humaton:fedora.im> I needed to check my calendar I am double booked next week but can take the one after to chair
2024-10-08 18:13:49 <@zbyszek:fedora.im> Any topics for open floor?
2024-10-08 18:14:07 <@zbyszek:fedora.im> I have something…
2024-10-08 18:14:09 <@humaton:fedora.im> state of the gitforge investigation
2024-10-08 18:14:17 <@zbyszek:fedora.im> jednorozec: go ahead
2024-10-08 18:14:53 <@humaton:fedora.im> here is a structure that might be usefull to represent our current distgit https://forgejoroute-communishift-forgejo.apps.fedora.cj14.p1.openshiftapps.com/rpms/mesa/issues
2024-10-08 18:15:13 <@humaton:fedora.im> there is org called rpms, few packages with issues mirrored from BZ
2024-10-08 18:15:31 <@humaton:fedora.im> same org/namespace is being populated in gitlab
2024-10-08 18:16:34 <@humaton:fedora.im> there is a bunch of small things that need to be tweaked so we can actually represent all the data from BZ+dist_git_pagure
2024-10-08 18:17:02 <@humaton:fedora.im> Do we know anybody who experimented with git LLFS at scale?
2024-10-08 18:17:14 <@humaton:fedora.im> Do we know anybody who experimented with git LFS at scale?
2024-10-08 18:17:22 <@nirik:matrix.scrye.com> I think gitlfs is a no go.
2024-10-08 18:17:41 <@jistone:fedora.im> are there mockups for any other than gitlab? or is that just the main candidate?
2024-10-08 18:17:42 <@zbyszek:fedora.im> Are customizations possible? For example hiding of unused branches, numeric sorting of `fnn` branches? Getting rid of Projects/Releases/Packages/Wiki ?
2024-10-08 18:17:43 <@humaton:fedora.im> even now?
2024-10-08 18:17:44 <@nirik:matrix.scrye.com> cool on forejo link
2024-10-08 18:18:23 <@jistone:fedora.im> oh, is forejo something else?
2024-10-08 18:18:35 <@humaton:fedora.im> yes yeas yes, I can give you admin role and you can turn those off by yourself
2024-10-08 18:18:57 <@humaton:fedora.im> I am currently working on custom template so we get tickets as QA needs to report package bugs
2024-10-08 18:19:26 <@jistone:fedora.im> oh, is forgejo something else?
2024-10-08 18:19:37 <@humaton:fedora.im> gitlab and forgejo are sollutions we are looking at
2024-10-08 18:19:48 <@humaton:fedora.im> I just always loose the gitlab link
2024-10-08 18:21:47 <@zbyszek:fedora.im> What about that huge list of user stories that was collected? Is the processed result available somewhere?
2024-10-08 18:22:36 <@sgallagh:fedora.im> And by "processed", hopefully that includes prioritization (at minimum, "need-to-have" vs "nice-to-have")
2024-10-08 18:24:05 <@humaton:fedora.im> So the list was processed, more like de duplicated. Some user stoires were merged. We as a tema of 2 people went through them and tied to test them
2024-10-08 18:24:45 <@humaton:fedora.im> once I have structure that can represent distgit+bz replacement linke the one in forgejo finished. We hope to get more feedback on it for both sollutions.
2024-10-08 18:26:00 <@zbyszek:fedora.im> What about gitlab?
2024-10-08 18:26:04 <@humaton:fedora.im> As it goes for minimum,need,nice to have. Yes that happened, minimum is set of the stories that cover package from creation to preparing data for build
2024-10-08 18:26:37 <@humaton:fedora.im> this is the bigges reason I am strongly agais gitlab https://docs.gitlab.com/ee/user/project/issues/related_issues.html#blocking-issues
2024-10-08 18:27:04 <@humaton:fedora.im> they choose the most critical feature of issue tracker to be premium
2024-10-08 18:27:17 <@humaton:fedora.im> but we can find workaround
2024-10-08 18:27:26 <@nirik:matrix.scrye.com> wow...
2024-10-08 18:28:47 <@humaton:fedora.im> I am linking forgejo now because I have it opened and am tweaking it, let me fill the gitlab with the same structure and update you next week.
2024-10-08 18:30:46 <@humaton:fedora.im> that all from me
2024-10-08 18:30:54 <@zbyszek:fedora.im> Cool, thanks!
2024-10-08 18:31:05 <@zbyszek:fedora.im> My topic was the sbin merge: I'm ready for another attempt. But it's too late to talk about this now. I'll send a mail to fedora-devel.
2024-10-08 18:31:13 <@zbyszek:fedora.im> Anyone else?
2024-10-08 18:31:27 <@zbyszek:fedora.im> If not, I'll end the meeting in a minute.
2024-10-08 18:32:11 <@zbyszek:fedora.im> !endmeeting