[Bug 251117] [NEW PORT] www/palemoon: Open-source web browser

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 07 Mar 2022 17:11:13 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251117

--- Comment #94 from Olivier Certner <olivier.freebsd@free.fr> ---
Hi,

Unfortunately, I have bad news. Upstream and I have ceased "collaboration".
Details on this development are available at the end.

It is now practically certain that they'll remove FreeBSD compatibility code,
maybe as soon as the next release (29.5). In any case, I advise users to start
considering alternatives to this port now (which might be running the official
Linux's version on Linux emulation, if that works; didn't test).

I'm updating the patch so that official branding is disabled by default.
Anybody can re-enable it for its own builds (they must just remain private). As
a service to existing users, if and as long as new versions continue to build
and work, I'll prepare patches for them.

Including the port in its current form in the ports tree has become irrelevant.
The browser should be rebranded and a new name devised before this can be
considered again.

If some people want to maintain a fork of Pale Moon's code base, first thing
will be to assess what needs to be patched to make the code run again on
FreeBSD once they have removed compatibility. The extent of this work is
unclear to me, but given we have in the ports tree most of their third-party
libraries, patches for them are likely to be reusable. I can provide minimal
support for that in the form of what I've learned and done so far, FWIW.
However, I don't plan to lead or even participate more than very occasionally
to such an effort, since my own priorities have been shifting. I'm now much
less interested in a customized GUI browsing experience than in modern web
support, large scale security scrutiny and cooperative upstream development.
Web compatibility has noticeably degraded in Pale Moon during the last year
because lots of sites have been switching to WebComponents or some unsupported
features of more recent ES standards. Upstream has been working on these during
this time, so at least they may be back on track on this front, perhaps as soon
as the next release. Unfortunately, as for genuine cooperation, they're still
not cutting it.

I would like to thank all people that supported this effort (and upstream does
the same), and especially ports management's members and ports committers who
have provided support and guidance. The effort was at times painful, but still
rewarding in some parts. I'm sorry I could not make it work. Hopefully some of
the people involved have learned a bit or two about communication, handling
user requests or the tradeoffs involved in accepting a port in the ports tree.

Regards.

-----------

I resumed discussion with upstream at the time indicated in the comments above,
i.e., after tcberner's comment about portmgr not blocking import anymore, my
fix to the port's recent compilation problem and further discussion indicating
that the port was in a good-enough shape to be included.

The owner, Moonchild, said that it was a little late, since they were about to
remove all BSD-specific code. He wanted to be 100% certain that Ports
management would completely accept some Pale Moon's peculiarities, such as
bundled libraries, and not just "tolerate" them, temporarily or not, before
possibly revising its plans. That's why I asked some more questions here and
relayed the answers (I thank again both tcberner@ and koobs@ for these). But
apparently, they were not enough for him, he wanted an official stance for Pale
Moon (that bundled libraries are OK), by fear of the port being arbitrarily
removed later.

At the same time, he started to exhibit paranoid behavior, first by questioning
the timing of the possible inclusion in the ports tree (why would I and ports
management "suddenly" make progress on this issue?). I thought he was saying
that because I came with news just as he was about to remove BSD-specific code,
which of course I didn't know. I did know about their intention to do it, but
not about any precise execution plan. Moreover, I had sent a message around
Christmas saying I was not able to work on including FreeBSD support into their
own build system before the end of the year, as I had committed to initially. I
never received any response, which I took to mean that they were too busy
(working on web compatiblity, on a MPL license violation, etc.). But I was
wrong about his fears: He was in fact thinking that we might have contacted him
again after he had sidelined Matt A. Tobin because of divergences, taking
advantage of the situation to solve a possible personal problem. Given some
other comments he had made, I thought I could reason him and show him he was
completely wrong and paranoid, but this proved to be a mistake.

On my side, I stated I was prepared to commit to more work on Pale Moon and for
2 years, while I didn't have a precise work schedule for them for business
reasons. Also, I wanted more reassurance that the collaboration could be
perennial before engaging in this. In this respect, I voiced several concerns,
especially asking up to which point he was actually backing or not Tobin in
some of its violent reactions (because that actually jeopardizes the
possibility to recruit co-maintainers or to find successors when I'm not here
anymore, besides threatening our existing relationship), and what his take on
2018's drama with OpenBSD was after he pretended that fearing redistribution
license's change on a whim was paranoia on our side (irrational behavior on
their part had already happened and done a lot of damage). Finally, I also went
on with detailing some possibilities technically and in terms of organization
as we would work forward. Unfortunately, he could not cope with my message nor
recognize any of their problematic behaviors. He mistook my own concerns as
objections to its quality assurance's concerns, which they had nothing to do
with. Finally, he did not respond to any of my detailed proposals, instead just
saying that we had no more basis for collaboration. Which I totally agree with:
If they are not able to even hear other's concerns (not even speaking about
respecting them), to inform them on their actions and cannot recognize how they
could harm perennial collaboration, then I refuse to invest more time in this
project. I don't think they know what genuine collaboration really is (or
perhaps I'm guessing too well what they actually mean by "collaboration").

All these were private messages, which I intend to keep private. I might
reconsider if they insist on challenging my summary of events though.

-- 
You are receiving this mail because:
You are the assignee for the bug.