On 03.03.22 17:23, Michael J Gruber wrote:
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
Hi Michael
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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
