On Mon, Jun 29, 2026 at 12:20:07PM -0500, Maxwell G wrote: > Hi Kashyap,
Hey, > On 6/29/26 9:47 AM, Kashyap Chamarthy wrote: [...] > > So much bloat. IMHO, all of this should be drastically culled and > > collapsed into one tool, if possible. > As Ben notes, part of this is by design and accounts for the different > states/stages of the Changes process, but ideally we can simplify parts of > this and make it easier for Changes to move between the steps without manual > work or opportunities for error. Sounds good. > > (2) Wiki change is copied to devel list > > This is needed for the community feedback stage. The current process > involves copying the whole proposal. This allows people and reply and quote > individual parts of the proposal. That makes sense, and is critical, of course. Maybe we could do away with the wiki. Submit a draft MR with the change, send a note to the mailing list with a link to the MR, ask people to reply on the MR itself. Aim to keep everything in _one_ place, as much as possible. > > (3) Wiki change is copied to Discourse (this splits the discussion; and > > adds broken formatting) > > I agree with you here, but if we do decide to keep Discourse, the new > process definitely needs to remove the possibility for these formatting > errors to creep in. Sure. I'm a bit torn on the Discourse/list split: Discourse allows those who are not on the devel list to also chime in. But it will also maintain the status quo of this split-brains situation. We'll be stuck with it "forever". Maybe insisit on having the debate on the MR? But it'll break people's preference for lists/Discourse. Stalemate. > > (4) FESCo ticket - voting > > FESCo votes are exclusively tracked in the FESCo tracker, so I don't think > we want to change this part. I wonder if we can skip this ticket and have the voting be done in the MR itself by means of ACK / NACKing change. > > (5) Bugzilla - some other kind of tracking? > > After FESCo approves a Change, Bugzilla is used to track the Change's > implementation, and any bugs identified with the Change's implementation are > supposed to Block that bug. If we moved to a different bug tracker, I assume > this part would change but not go away completely. Any reason we can't track the Change's implementation in the MR that is implementing the said change? Use BZ / Forge for bugs. But I get it, using a single "Blocks On" / "Blocks" in Bugzilla is helpful (I don't know if such a thing is possible in Forge). -- Kashyap Chamarthy / Red Hat / RISC-V and Fedora -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
