Hi Michael
On 2022-03-03 15:47, Sandro Mani wrote:
On 03.03.22 15:30, Michael J Gruber wrote:
> So, I explicitely asked what your plan was and got no response.
>
> I suggested to fix the problem at the root package and you went ahead rebuilding depending packages.
>
> I asked you to use proper commit messages/changelog if you do and got a series of "Rebuild (leptonica)", "Bump as F36 needs another rebuild" and what not.
>
> I asked you to at least reference the bz entries and you did not.
>
> While I'm typing this a buildroot override comes along.
>
> We do have an "unresponsive maintainer" process. Do we have an "unresponsive irreponsible proven packager" process, too?
To be honest I'm saddened by such hostility. I maintain a pretty large
number of packages mostly in my free time, and I think it's fair to say
that I maintain most of the mingw and stack alone. I undertook a pretty
large effort to merge some mingw specs into the native specs reduce my
workload in the future, often working late into the night. At one point
I did 197 commits in one day, and for as much effort and concentration I
put into it, mistakes do happen - I am only human. But I think I've
always been responsive and taken care to address any issues in a timely
matter. So honestly, rather than attacking people for commit messages
and attacking me for "the problems I caused last time", you might might
consider using a more friendly tone.
Sandro
I completely agree with you that communication is key. That is actually my point, and that's why the guidelines require or strongly suggest communication when a library change affects dependent packages or when a proven packager commits into "someone else's" packages (I know nobody "owns" a package). And I'm not insisting on any points literally here - I'm completely fine with a push from which I can tell what's going on, even without prior communication or coordination. We have pull requests, we have bugzilla entries, we have commit messages to support communication in many ways, it does not have to be by e-mail.
What offends me is complete "non-communication": if, as a proven packager, you push "Rebuild (tesseract)" to mupdf.git I have to find out myself why you can even push to that repo, why you are doing that, and I have to live with that non-descriptive changelog entry (due to %autochangelog). Plus I have to close the non-referenced bugs. That's what happened "last time" (december), and even though it bothered me quite a bit I didn't complain.
Uhm, I wouldn't classify [1] as non-communication. As I believe is pretty standard procedure, the change was announced to fedora-devel, indicating the steps which will be taken and if any action by others is required - in this case, I wrote that I'd take care of rebuilding all affected packages. A commit message of the form "Rebuild (xxx)" is actually pretty common as far as my experience over the past 10+ years packaging goes, if you prefer to see "Rebuild for XXX soname bump", well I suppose why not. But classifying this as "complete non-communication" is I believe pretty unfair.
Another point: to a certain degree, as a packager, you are always
trusting upstream to ship a working product. What happened later
is that it turned out that the cmake build scripts of tesseract
were pretty much broken. The issue was pointed out and, as
documented in [1], I promptly reacted to fix up the package
(delayed a bit while trying to figure out an armv7hl build failure
due to incorrect cflags ordering, hurray debugging build scripts).
Now, since we're having the same with leptonica, I *asked* you to do it differently. What I got in response was no response but the same kind of pushes. I consider that inappropriate, and the tone of my last posting was a desperate attempt to get some form of communication going.
This one was a combination is things: When working on merging native and mingw packages (change which I announced), I opted for cmake whenever support is available, since it leads to cleaner packaging. So also for leptonica, I opted to switch to cmake, with the intention of providing compat symlinks to avoid any effect for other packages. As I wrote, I forgot the symlink for the versioned library. I judged that most robust way forward was to just rebuild the small number of affected packages. In the space of a couple of hours all was done, except, blame running to fix the problem, I didn't notice that in the meantime bodhi was activated for F36 and some packages were build against the old leptonica package. So I needed a second rebuild to ensure that NVR in F37 was >= NVR in F36.
Pehaps a general request here: it would be useful if fedpkg could give you a note when bodhi is active for the build target.
I admit that I was pretty much put off by your remark regarding "problems I caused last time" which I don't consider appropriate, so after ensuring I took all the necessary measures to leave a clean package state, I dedicated some time to other activities.
So, please reconsider your communication strategy as a proven packager.
As you'll have read on devel, I've announced tesseract-5.1.0 and proj-9.0.0 landing in rawhide in the next days. I'll be again rebuilding all affected packages, so this includes mupdf. If you want to double check, I've linked the copr repos where I'm testing the work in the post announcing the change. I hope this is considered as sufficient communication.
Sandro
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
