On 12/18/24 8:26 PM, Kevin Fenzi wrote:
Since I have not chimed in on this yet, let me just say that I am deeply sorry how the communication/timing/process went here. At the least I should have realized that many fesco members would be already away this week, so with lack of quorum, it's hard for fesco as a whole to respond or take actions. I too am one of those who is supposed to be away, but I've found this week far from relaxing. ;(
Please make sure to 'plug out' and take time for yourself and others that are important to you as well.
A bit of history for those that haven't been around a long time: (at least from my memory, please do let me know if I misremember here!) ...snip..
I *really* like tidbits like this. Thank you for the story it contains many things on why people might have different ideas of the roles and process for provenpackagers depending on when they joined the Fedora project.
I personally kind of like the idea of telling provenpackagers to use pull requests, but I don't thats sufficent. It should be a pull request that also explains why. "Update to new version" isn't good enough communication. It should be "Update to fix build because this is needed for foo which has a serious bug which I am trying to fix before users hit it" or something similar would be much better. I wonder if perhaps now (or with a new gitforge) we could also raise visibility somehow? A weekly report of "here's the things provenpackagers did" and we can get more data on who is doing what for what reason. If there's packages that provenpackagers are often committing on perhaps they need more help?
We could, but it's might be difficult to tell which hat someone was wearing at the time a certain PR was made.
I don't think we can change the policy with hard timelines. Urgency and importatance will be subjective and could be wildly different between cases. However, again something to think about with a new gitforge is perhaps we should have a lifecycle for everything? ie, if you submit a pull request right now, it just sits there until closed or merged. Even if it has conflicts. Even if it's against f37 or something.
What I'd like to see is to remove provenpackagers, do everything through PRs and have a separate SIG/group that can fast-track and merge any PR. This lets us verify that the changes are clean, minimal, and still allows some human fast-track to skip some checks and balances if we must.
There could of course be some sort of exception(s) for mass rebuilds or such.
Finally we should clarify the arch teams. When aarch64/ppc64le/s390x were moving into primary we did have a ton of activity and there were things that needed pushed quickly to get things working. Likely the same will be the case for riscv. At the start of them being primary we still sent arch teams bugs and issues to deal with, but I think slowly over time thats eroded and since most of those are just mainstream now, maintainers often just handle issues themselves with upstream help. Do we still want provenpackagers from those arches to push fixes? I would argue yes, but again communication is very important.
I do think a new gitforge may be a good chance for us to adjust our workflows both to it and to better serve everyone.
Perhaps a lot can be done with the new forge but we shouldn't ascribe it mythical properties. A PR-like workflow will hopefully be easier in ForgeJo and managing ACLs likely as well.
For the rest we'd need a bunch of CI and bots (however: I really like the idea of auto-closing/rebasing PRs against old branches). There's definitely a lot we can gain here.
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
