[Bug 214070] www/firefox and other mozilla ports: split release candidates off into firefox-devel

[bugzilla-noreply at freebsd.org]

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

Jan Beich (mail not working) <jbeich at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|maintainer-feedback?(gecko@ |maintainer-feedback+
                   |FreeBSD.org)                |

--- Comment #1 from Jan Beich (mail not working) <jbeich at 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 individual
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 major
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., 49.*
had ports r421532 ports r422464, ports r422465, ports r422711, ports r422956 or
ports r423591. Our quaterly branches (e.g. 2016Q4) are better suited for users
that want less frequent updates. But thanks for reminding me I shouldn't merge
candidates there.

www/firefox-esr rarely has non-build1 candidates as ESR branch isn't supposed
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.

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