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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251117

--- Comment #92 from Kubilay Kocak <koobs@FreeBSD.org> ---
(In reply to Olivier Certner from comment #91)

That's fine to ask, and the reason its difficult to get a grasp of things is
that its challenging to be entirely precise and entirely objective about the
issue as it relates to 'what is the right thing to do'.

With hard and fast rules this is easy, but there's multiple considerations here
(and with other types of issues and questions) too, which are worth
enumerating.

Note that the perspective below is more 'lets try to eat our cake and eat it
too as much as possible', or 'how much of the best of all worlds can we have',
rather than 'this is the one rule for this exact situation with no exceptions'.

The following are "desirable or relatively uncontroversial
statements/attributes' that all trade of against each other", that different
people and contexts value things differently, and over time. Keep that in mind.

- We want users to have easy access to as much software in ports as possible

- We want packages/ported software to be of high quality and maintained well

- It takes contributor effort/time for all of this to occur.

- It's 'nice' to bias action over stagnation, vs other tradeoffs.

- We want this to take as little effort as possible, vs other tradeoffs

- There are tradeoffs between bundled and unbundled dependencies 

- There's a defacto standard, not just to depend on port versions of
dependencies, but unbundle them where they are bundled. Most stuff in the tree
is 'of this form'.

- There is 'variable' effort involved in unbundling dependencies depending on
project, complexity, skill, etc. From trivial to 'excruciatingly complex'.

- Some things in ports are not un-bundled because:

 * the effort required to do this is too high, or not worth it, OR 

 * we cannot manage to stay up to date or at a high quality if we did that, OR

 * people just didn't do it, and we don't have a strict or enforced QA policy
or capability or culture to require/demand it, OR 

 * the ecosystem tends not to work that way (see nodejs, etc)

On the last consideration, there's additionally:

- should we 'deviate from upstream and community norms and conventions', OR
- stay as close to upstream as possible, AND
- why or why not? (there are tradeoffs here too), AND
- how does this decision tradeoff against everything else?

All of the above are not palemoon / this issue specific, and I've tried to stay
away from 'opinions' (mine or otherwise).

To answer your question, specifically, in my opinion:

> What did lead to this decision after so much time? Only the arguments > presented here?

- Any 'main' issues raised in this issue that might have *clearly* (rules) been
reason block a port (license, branding, etc), have been sufficiently (if
ambiguously) expressed and are not of *sufficient concern* or *remaining
ambiguity* to warrant people wanting to be on the hook publicly for blocking
it.

Had portmgr not explicitly been asked for feedback, we may not be in the
current position. 

The re-triage in comment 61 was *exactly* an attempt to 'demuddy the water',
given the issues long history and very very verbose nature, which contributes
substantially to stagnation generally, and bring the issue to a head
explicitly.

Either people were going to raise remaining issues, or it was going to move,
one way or another.

All of the above is the best context and detail I can provide. I hope its
helpful.

Last update is we're waiting on a patch and feedback from them is pending
(maintainer feedback ?)

This issue now needs:

1) A final and thoroughly QA'd patch (needs-patch) (needs-qa)
2) A final review after attachment here (needs-qa)
3) A committer to be committed

Note 1: *Anyone* may provide (1) and (2).

Note 2: *Any* interested committer may *at any time*, self assign the issue to
coordinate its resolution.

I suggest everyone focuses only on (1) and (2) at the present time.

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