Peter said:> some are *ignored*, some *sit for months without action*, others have outlined this in the thread as well. If there was a way where people *put a readme* or something with details I believe it would remove a LOT of the friction. (emphasis added).
I think there is a frustration also with the lack of communication with the main admin in certain packages, and the turn around time for PR from main admins. It would be best that the main admin of a package engages with PRs quickly, and communicates things clearly on the PR, so contributions are understood and aligned, and they are accepted or rejected quickly. It can be greater frustrations if they are just ignored. It seems to me that it goes beyond roles, but also expectations of communication and turnaround times. If the PP role is completely removed from Fedora, for example, the frustration described here would remain, together with its impact on the Fedora project.
On 12/16/24 4:18 AM, 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! Contrast that with the fact that we start an irresponsive maintainer process in these cases ...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: - 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. In particular, "proven packagers" are not even part of the team of admins which shares responsibilities for an individual package.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. 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. In all of these cases, there was no "hindsight insight", instead lot's of "it's only SHOULD" and "I had to do it to solve *my problem*". This lacks the responsibility that I talked about above, and it only adds to the list of excuses (or rather "lame justifications") that people came up with here in this thread (not specifically Daniel): - "Just give him a chance, he didn't know" (when FESCo mentioned previous communication and same behavior thereafter, plus the chance to reapply.) - "Wy do yo mention the clear name, not just FAS" (when the FAS handle is initial lastname ...). - "Why are you not transparent" (after complaining about mentioning the name). Last time I checked, FESCo was elected *by us*. This comes with power and responsibility, but hopefully also with a certain amount of trust that we put into them. This doesn't mean that we can't question their decisions. But I'd hope we do that with a constructive mindset (rather than sowing unfounded distrust). And I'm thankful to FESCo for making it clear that if you share power you share responsibility. Michael
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital 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
