Date: Wed, 02 Nov 2016 23:09:11 +0000 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 Message-ID: <bug-214070-21738-DTyNZKkpvq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-214070-21738@https.bugs.freebsd.org/bugzilla/> References: <bug-214070-21738@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214070 Jan Beich (mail not working) <jbeich@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|maintainer-feedback?(gecko@ |maintainer-feedback+ |FreeBSD.org) | --- Comment #1 from Jan Beich (mail not working) <jbeich@FreeBSD.org> --- (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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-214070-21738-DTyNZKkpvq>