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. ;( On Mon, Dec 16, 2024 at 12:01:11PM +0000, Daniel P. Berrangé wrote: ...snip... > While there can be reasons to push directly to git, I think it should be > considered very exceptional. Again I think this would be helped if the > guidelines explicitly said that opening a PR is the strongly favoured > default approach. > > Personally, I would aim to mandate PR is used exclusively for everything > done in Fedora. Even if that PR gets immediately almost approved & merged > by the same person, it at least enables automated CI to catch clearly > FTBFS problems. This would need very good automation to make it scale > in the scenarios where large distro wide changes are needed. So today I'd > be fine with just saying PRs are simply the default strongly preferred > option. It'd be better than the vague language used today about how > PP should communicate with maintainers. I think it's pretty clear we need to try and get some more clarity around communication here, so I think this subthread is worth continuing. 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!) In the 'fedora extras' days anyone in the packager group could commit (cvs!) to any package. (ie, everyone was provenpackagers) At the start of fedora/extras merge, anyone in the packager group could commit to lots of things. However there were a few ex core packages that were locked down. In 2008 ish, this was changed: https://fedoraproject.org/wiki/User:JesseKeating/NewMaintainerContainment https://fedoraproject.org/wiki/User:JesseKeating/NewMaintainerContainment and as part of that a new group was made: uberpackager! https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/EFZWNCWZTU33B3YWXJNZRBQEH7YZLRI5/ (and a 99 post thread about the name, which was changed to provenpackager). As part of this some packages could still choose to not allow provenpackagers commit. The early docs had: "To become a provenpackager, you must ask an existing provenpackager to sponsor you into the group. This is a much less involved process than initial sponsorship. Usually just asking is all it will take. Most maintainers probably will not need to be provenpackagers, so you shouldn't apply for this access unless you need it." https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group&oldid=81650 I remember (but can't find my meeting logs from, so I might be mistaken) that the idea at the time was that provenpackager should be very easy to get. You just needed someone to vouch for you that you knew. Also, the initial provenpackager group was seeded from packagers with > 5 packages (or something similar). Anyhow, not sure thats too useful, but I thought it might inform on things we have done/tried in the past. There's a bunch more of course. 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? 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. 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. kevin
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ 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
