Dne 05. 12. 23 v 5:56 Jason Tibbitts napsal(a):
Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> writes:My pet peeve is provenpackagers or comaintainers who add unwanted automagic (autorelease, autosetup, autochangelog) to my packages.That really shouldn't be happening for anything which wasn't officially made mandatory or forbidden or whatnot. Sure, I went through and removed Group: tags long ago, and the same was done for ldconfig scriptlets and such, but that was only after the whole thing had gone through the change process. I can't imagine it would be appropriate for a provenpackager (who isn't also explicitly listed as a maintainer for a specific package) to just make a fundamental change to package maintenance like that with no discussion. I would think that if it did happen, it would definitely warrant an apology.
I just want to say that during my proven packager years, I certainly did substantial changes to other's packages, but I was pretty sure that the package was not maintained by anybody except proven packagers. I still find surprising, that we can have packages like that.
E.g. looking at https://src.fedoraproject.org/rpms/rubygem-json/commits/rawhide
How comes the package was not orphaned by some automated process yet, to find a rightful maintainer?
Can we also make a rule that if package reaches e.g. release 10 with only mass rebuild commits, it will be orphaned? I have a few examples at hand:
https://src.fedoraproject.org/rpms/rubygem-ansi/commits/rawhide https://src.fedoraproject.org/rpms/rubygem-daemons/tree/rawhide https://src.fedoraproject.org/rpms/rubygem-elasticsearch-transport/commits/rawhideI am not going to continue, but from these 3, the rubygem-daemons looks reasonable (but without enabled test, so nobody can tell if the package works) to today standards, because it was touched by proven packager years ago.
How I know about these cases? Because from time to time I look at the packages which are not migrated to SPDX yet. Will these be migrated? I don't think so. Should proven packagers do that?
There are also cases such as https://koschei.fedoraproject.org/package/rubygem-async_sinatra which is FTBFS for a while already. Should I fix the package as a proven packager knowing it is broken (also knowing the reasons for the breakage and the fix should not be hard), or should I leave it, because it does not seems to be maintained, while I don't think the maintainer is completely inactive.
Granted, these are dissimilar to initial Michaels's issue. But how can I be sure that if I touch some of the packages, I won't be told that they were in such state for purpose?
Sorry for bit of OT. Vít
But, fixing bugs and FTBFS issues? That's absolutely part of what we would expect provenpackagers to be doing. - J< -- _______________________________________________ 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
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
