From owner-freebsd-gecko@freebsd.org Wed Nov 2 23:09:13 2016 Return-Path: Delivered-To: freebsd-gecko@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55C94C2CC32 for ; Wed, 2 Nov 2016 23:09:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0167F1C06 for ; Wed, 2 Nov 2016 23:09:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id EDF01C2CC31; Wed, 2 Nov 2016 23:09:12 +0000 (UTC) Delivered-To: gecko@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED76DC2CC30 for ; Wed, 2 Nov 2016 23:09:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD94A1BFF for ; Wed, 2 Nov 2016 23:09:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uA2N9BTJ061603 for ; Wed, 2 Nov 2016 23:09:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: gecko@FreeBSD.org Subject: [Bug 214070] www/firefox and other mozilla ports: split release candidates off into firefox-devel Date: Wed, 02 Nov 2016 23:09:11 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: flagtypes.name 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 MIME-Version: 1.0 X-BeenThere: freebsd-gecko@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gecko Rendering Engine issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 23:09:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214070 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|maintainer-feedback?(gecko@ |maintainer-feedback+ |FreeBSD.org) | --- Comment #1 from Jan Beich (mail not working) --- (In reply to Martin Birgmeier from comment #0) > While this has the advantage of quickly exposing new features to the > general public, It also means quickly fixing security vulnerabilities that upstream hasn't = yet published but the bad guys may already be using or can deduce from individu= al commits. > it also means that potentially unstable code is being distributed. Such code can end up in releases as well, otherwise there'd be only one maj= or version each iteration (6 weeks). Not to mention any major Firefox release = is potentially unstable because upstream considers FreeBSD a Tier3 platform i.= e., no one is assigned to check for our regressions. And I'm not interested in debugging broken builds, crashes or runtime regressions specific to old versions. If you want the most stability maybe switch to www/firefox-esr. > Furthermore, this is done in a rather intransparent way, as one cannot > deduce from the version designation that a release candidate has > actually been installed. A release candidate may be promoted to an actual release in which case the distfile wouldn't change, so the package has to stay the same. If a new one appears before release, PORTREVISION is bumped. So, users shouldn't try to deduce versions in order to skip some but upgrade packages regularly. > A further disadvantage is the rapid succession of new releases with little > relevant changes requiring frequent updates. www/firefox has PORTREVISION bumped often for other reasons as well e.g., 4= 9.* had ports r421532 ports r422464, ports r422465, ports r422711, ports r42295= 6 or ports r423591. Our quaterly branches (e.g. 2016Q4) are better suited for us= ers that want less frequent updates. But thanks for reminding me I shouldn't me= rge candidates there. www/firefox-esr rarely has non-build1 candidates as ESR branch isn't suppos= ed to carry anything but bug and security fixes. If it has more candidates then something was rushed through upstream QA process which makes the update more risky. > I therefore propose to split off -devel versions of these ports where > users who want to stay on the bleeding edge are served the release > candidates as is currently done on the main ports. The main ports > themselves should revert to only upgrading to truly released versions. -devel suffix is for ports that snapshot development branch i.e., mozilla-central in this case. What you probably meant is -beta but release candidates are more are of its own flavor. However, I don't plan to create = new gecko@ ports as it'd increase maintenance. Some refactoring needs to happen first in order to increase bus factor and expand the team. --=20 You are receiving this mail because: You are the assignee for the bug.=