Thank you to everyone here who explained the context of which I was unaware surrounding this issue. I appreciate that you took the time to do that. A couple points in response...
* For the record, if the package maintainer had said in the other ticket, "Yes, the package is broken, but including Selenium Manager in the package is not currently possible because the tools to build it in Debian don't exist and that's not a trivial problem to solve," then we would be having a very different conversation right now, and I would never have escalated this to the technical committee. Instead, what they said was (paraphrasing), "I don't think we should consider the package broken just because it used to work and now suddenly stopped working and the same code that used to work now causes a stack trace, because if the user reads the stack trace and spends about 30 minutes Googling they should be able to figure out how to work around the problem." This is not, in my opinion, a reasonable response. Just because fixing the issue "correctly" involves a lot of work we can't currently do doesn't make that a reasonable response. I realize that adjudicating whether a response from a maintainer is reasonable is outside the purview of the technical committee and I'm not asking for a "ruling" on this one way or another; I just feel compelled to point out that the only reason why I escalated to the technical committee was because the maintainer was not forthcoming.
* I want to push back a bit on the attitude I seem to be hearing
here, that people shouldn't report issues unless they're prepared
to do the work to fix them, or the corollary, that if no one is
currently prepared to do the work to fix an issue then it should
just be closed. I don't think people should be rebuffed from
reporting real issues just because they don't have the skills or
time necessary to fix them themselves, and I think that unresolved
or incompletely resolved issues should be kept open until they can
be resolved properly.
* Speaking as an end user, I do not agree with the statement, "I
see that python3-selenium now has a NEWS.Debian entry that points
to README.Debian, which seems like a reasonable way to bring this
to users' attention." Most users don't know to look for either of
these files. It's simply not going to occur to them that this is a
Debian issue requiring special handling; they're simply going to
think the package is broken. I could be wrong about this, of
course, but this is my gut instinct. Given that the Python code is
always going to crash in the same place if it can't find Selenium
Manager, then a workaround for this problem would be patch the
code so that it catches the exception and points the user at
README.Debian before re-raising it.
* If this really is going to be "fixed" just with documentation, then I would argue that the better documentation fix would be to tell the user how they can install Selenium Manager themselves rather than telling them how to hack their code to work around the missing Selenium Manager. That would mean telling amd64 users where to download it, and providing instructions for users on other architectures on how to compile and install it. Heck, maybe even put a shell script in the python3-selenium package that compiles and installs it and just tell the user what it does (full disclosure is important here!) and how to run it.
If there is interest in a combination of the above two changes as
an acceptable improved fix for this issue, and someone can point
me at where I can get started learning how to submit patches to
Debian packages, then I am willing to work on this and submit a
patch.
* I agree that patching the Python binding on Debian to restore the previous behavior would be a better short-term fix than what we have now (though I think a combination of the two fixes above would be preferable). However, I'm not sure that's a viable long-term fix, because I imagine that if Selenium Manager "catches on" it will become harder and harder to patch it over time. There's no saying whether I'm right about that or if I am what the time-frame will be, and it could actually go in the opposite direction, i.e., if the maintainers of Selenium get enough push-back about their choice to require their Selenium Manager binary they may reverse that decision.
* Another potential fix for this is to package Webdriver Manager, which is essentially a pure-Python replacement for Selenium Manager, make it a dependency of python3-selenium, and patch python3-selenium to use it by default instead of Selenium Manager. I think this would satisfy everyone's concerns, and it would restore python3-selenium to a working state out-of-the-box.
I am also willing to work on this and submit a patch if there is
interest in this solution.
* In my opinion, keeping the old version of the Python bindings
that didn't require Selenium Manager would have been a better fix
than upgrading to a version that doesn't work and requires the
user to make platform-specific changes to their code to make it
work. Granted, this too is only a short-term fix, so it would only
be a stopgap measure until such time as Debian figures out how to
build and package Selenium Manager. So this isn't a workable
solution if that's unlikely to happen any time soon. If there *is*
progress being made on that, and none of the other possible
solutions I've enumerated above are considered workable for
whatever reason, then I think this one should be considered.
Thanks,
Jonathan Kamens