OpenBSD & Pale Moon: coordinating patches and officially branded package?

Talk about code development, features, specific bugzilla bugs, enhancements, patches, and other highly technical things.

Moderator: satrow

Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific referenced Bugzilla bugs, mercurial, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Most "bug reports" do not belong in this board and should initially be posted in Community Support or other relevant support boards.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 23648
Joined: 2011-08-28, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread post by Moonchild » 2018-10-14, 05:46

The system library issue is not just about performance. I've explained this before already. Building against unknown types and versions of sytem libraries is almost guaranteed to cause stability issues, and for a complex piece of software there are too many snags and hooks with the interop of dozens of libraries to reasonably cater to all of them. It's not possible to test every version of every library possible. If we can't guarantee reasonable stability, we don't want it to be carrying the Pale Moon label. The same goes for security of libraries contrary to what you posted: it is not unidirectional that a later version of a library will always be "more secure", or that any later version of a lib is actually addressing a problem in the browser (or instead might be causing problems). Any sec updates to libs that are prudent are always addressed by either porting patches or by upgrading the in-tree lib...

So, in short, the system lib setup can neither guarantee a reasonable level of stability nor security of the final product and it's our simple right to say we don't want our label on it.

Aside from that, the way the whole dialogue went has closed that particular door. Not because of technical contention but rather because it was approached as if we had to relinquish our branding rights which I will not do. The wording could have been better on both sides but it remains a fact that we are already being more lenient here than we have to be under open source development practices, including the GNU philosophy. We are not going to treat this as public domain, ever, because it simply isn't!
Last edited by Moonchild on 2018-10-14, 06:08, edited 2 times in total.
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne
"I'm afraid you have me mistaken for someone who can be shamed by a child." -- Quillspawn

Locked