From nobody Fri Feb 25 00:48:31 2022 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0BA0419CE587 for ; Fri, 25 Feb 2022 00:48:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4WNc68vlz59Kc for ; Fri, 25 Feb 2022 00:48:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B4FE71635C for ; Fri, 25 Feb 2022 00:48:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 21P0mWkM094410 for ; Fri, 25 Feb 2022 00:48:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 21P0mWrb094409 for ports-bugs@FreeBSD.org; Fri, 25 Feb 2022 00:48:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 251117] [NEW PORT] www/palemoon: Open-source web browser Date: Fri, 25 Feb 2022 00:48:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: feature, needs-patch, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645750112; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5Y4aC7zXe9v0FmdN/7iJ0DZ0f4u2IbD+lIb/p0l5l2M=; b=K9L+mRv4iUz+7nGmXTg6cFVzLUHyAsPLXEo2+PYxhBBPEdNEp9ALR7yLaRbvqGGy3CEilH xn2ibPOm2NlyUfuk/ie6NN+QMk9+aMYmaCvvpNMIvP1luHu//AWc05jKPtlVfM6htRe8Qq VFSVbktuXn7sSzxOHpji8p6wGitOiBHW3ff4VIzph9oODKaZ2rLmekw0P728dEyjA4VJqJ 9nZPjWCNhMOCcaKBwomHe7vJuuMmQ1rHsAp6/MjtOeJwLu+sz2752m+H7JQ61KZmdB/iSk g6GEZ9fk9ODEu3ngX2t//y1CxEGb3ZIeT3jTPa5970Aclg4rCT6CncnAurYl9w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645750112; a=rsa-sha256; cv=none; b=LhvUqxAkIrc1lFRnb4HHTKD9mNJQd0fFu8ubqNwvwJ8g+s9ZGlVf1sXTo8qlVAg5+yKUgW KeeFg47akzZwNqOnlfWzfWy/ibPslWCd1IoExjcahbf2Z58v7faKKd29v37CH5tUIingdl 9HrgKl97tcBYvfHvXacSHjot8SNb2HQA2QFRtF6h+MHNJ/igwbVUs6ePBsVxwIHIJIdopv 8PgIVt2T8pDvMqxHyAYB34OsKXrjinIa6MT20mHI8AD3Z95zK2GWxEPMj6P1eaTYtzpx0a D4NPccErp+/OlfjSiVMqOc7B9AWH15q0XrxSkWsEsZjgx/COyEw+yohatg9CFQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251117 --- Comment #92 from Kubilay Kocak --- (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 hav= e', rather than 'this is the one rule for this exact situation with no exceptio= ns'. 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 m= ind. - 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=20 - 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 t= ree 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=20 * 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 poli= cy or capability or culture to require/demand it, OR=20 * 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 > p= resented 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.=20 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 contribut= es 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. --=20 You are receiving this mail because: You are the assignee for the bug.=