On 16. 12. 24 18:42, Adam Williamson wrote:
On Mon, 2024-12-16 at 08:25 -0800, Adam Williamson wrote:
On Mon, 2024-12-16 at 10:17 +0000, Daniel P. Berrangé wrote:
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.
It's also difficult to really always honor. As a PP I certainly touch
packages without checking in first, sometimes, when it's necessary e.g.
to fix Rawhide compose or a problem that's causing tests to fail for
all updates, or something.
In fact, let me confess - just this weekend, I built seven packages
without sending PRs or contacting the maintainers.
Why? Well, libphonenumber 8.13.50 inadvertently changed symbols without
bumping the library soname, so we had to rebuild all its deps. Then
8.13.52 reverted the change, so we were back to the original
symbols...but since 8.13.50 had hit Rawhide and we'd rebuilt everything
for it, now we had to rebuild everything *again*. I co-ordinated this
with the libphonenumber maintainer. He built 8.13.52 on a side tag, I
rebuilt all the deps on the same side tag, he submitted an update.
Yes, I *could* have contacted the maintainers of all seven deps and
said "hey, I'm going to do a no-change rebuild of your package so it
goes back to having the libphonenumber symbols it had before", and
waited a week for all of them to reply, or not. I *could* have sent
pointless PRs for all seven packages - pointless because for the ones
that use rpmautospec they'd have contained nothing but an empty commit,
for the others they'd have contained a release bump and a changelog
entry, and for all of them the CI would not have built against the side
tag anyway.
But I didn't, because honestly it seemed silly and I don't want to have
all that pointless process hanging over my week/weekend. So I just did
the bumps and built the packages, Sergio submitted the update, and
everything is apparently fine.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-376cb0546e
This kind of thing does go on, whatever the letter of the PP policy
says. I don't think it's really causing any problems, and I'm not sure
things would be *better* if I had been somehow forced to send out
mails/PRs about this. Maybe if there was a *better* PR-based workflow
where the library PR and the dep PRs somehow all went together or were
one PR, that would be good? But since there isn't...
I am not sure if this is or is not explicitly mentioned in our policies, but
I'd say it is a common understanding that changeless bumps-and-rebuilds are
performed like this. Nobody expects you to open PRs to rebuild packages for a
soname bump etc.
And based on my experience, I doubt this particular provenpackager status was
stripped based on something like that.
Sure, I guess we all agree that the line is fuzzy and probably not very well
documented/defined. That does not mean we use that to justify problematic
provenpackager behavior.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
_______________________________________________
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
