On Mon, Dec 16, 2024 at 12:18:00PM +0100, Michael J Gruber wrote: > Daniel P. Berrangé venit, vidit, dixit 2024-12-16 11:17:35: > > On Sun, Dec 15, 2024 at 04:49:32PM +0000, Richard W.M. Jones wrote: > [snip] > > [snip] > > > > > I do think we need a bit less ownership and a bit more shared > > > responsibility with packaging. For packages which I maintain, I'm > > > happy for PPs to touch them without getting permission beforehand. > > > Just try to do the right thing! > > > > Yes, the notion of "ownership" is what gives rise to the situation Peter > > describes above "everyone ...has their own preferred way of doing things", > > that PP have to be aware of to avoid conflict. > > > > We should consider Fedora packagers "custodians" rather than "owners". > > Fedora owns the package, maintainers are looking after it on behalf of > > Fedora. > > We should not forget that the interpretation of "proven packager" is at > the origin of this dispute, and the relation between what pagure calls > "main admin" and a "proven packager" > > main admin/owner/maintainer come with a notion of *responsibility*. When > we talk about (and possibly, clarify or change) the relation between > "main admin" and "proven packager" we have to talk about > responsibilities. > > If a package is Fedora's resposibility (not the main admins) then > ignoring BZs and PRs is perfectly fine! As all Fedora maintainers are volunteers, ignoring BZs and PRs is fine if their time demands are too great for what you can afford to invest curently. That is one of the reasons we have proven packagers as a concept - to step in to handle problems, if the regular maintainer is not able to do so themselves currently. > > By all means have personal preferences, but if someone is following > > documented Fedora procedures that should be considered fine, even if > > it doesn't align with personal preferences. > > No, that's not even how you can work in a team of people with equal > rights. Every team of people has to find a way of how they work > together. Just as an example: I didn't suggest everyone has equal rights over a package. Just that proven packagers should not be expected to guess each maintainers personal preferences for how they need to be contacted before a change. > - Using rpmautospec is documented Fedora procedure. > - Not using rpmautospec is documented Fedora procedure. > I"m "admin" (co-maintainer) of packages which do not follow my > preference in this regard, and *of course* I do not simply change the > package to follow it. Proven packagers should not do this either. > > I"m not saying that you suggested PPs change rpmautospec or someone did, > and I'm not involved in the current "case" in any way. > This just shows that "anybody by their preference" cannot work and never > will. Some parts of the guidelines are just "bikeshed colouring" within scope of the package, with the choice not significantly impacting other parts of the distro, or impacting workflow processes. That's totally ok, and rpmautospec is something I would (currently) put in that category. There's no scenario I forsee in which a proven packager would have a blocking problem that requires changing the rpmautospec choice. Other parts of the guidelines affect things outside a package and or affect general processes. Those are areas where I think Fedora shoudl always aim to be explicit about what's expected. How a proven packager should contact maintainers is something in the latter bucket, and IMHO should be explicit about the recommended approach, and not list countless different possible communications ideas to suit everyone's personal preference. > > I myself have a preference that we put changes to libvirt spec upstream > > first, but ultimately Fedora trumps that preference. So if a PP comes > > along and merges a change downstream only, its my job to reconcile that > > upstream. That's ok. My preference simplifies my life 95% of the time, > > and lets PP still do their job downstream when important. > > > > Looking at our guidance > > > > https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ > > > > It is very non-specific > > > > "Prior to making changes, provenpackagers should try to communicate > > with owners of a package in bugzilla, dist-git pull requests, IRC, > > matrix, or email." > > > > This is sooo vague & open to interpretation I can easily see how differences > > of opinion can arise from this. If you send an email, how long do you have > > to wait for a response ? If you don't get an email response do you have to > > open a bugzilla too, or is lack of email response enough to allow you to go > > ahead ? If 1 communication attempt is not sufficient, is two different > > attempts sufficient, or do they have to try all 5 methods of communication > > listed ? Combine that with "personal preferences" and it is surprising there > > are not more conflicts seen. > > If you go by "should vs must" then no communication at all is fine, too. I don't think 'no communication' is fine. Just that we should document the preferred approach, and that maintainers should be OK with the preferred approach being used, even if they would prefer other comms approaches ordinarily. > Again, I'm not involved in the current case nor referring to it. But > when I got mad at PPs in the past it was when "communication" consisted > of a mere push straight to the main branch; at times with suboptimal > commit messages; sometimes even pushing FTBFS commits. 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. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ 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
