[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: www/firefox-esr instead of www/firefox[0-9]*
nia <nia%NetBSD.org@localhost> writes:
> On Tue, Dec 17, 2019 at 03:47:35PM -0500, Greg Troxel wrote:
>> I have come around to treating firefox-ESR as its own upstream. I am
>> sympathetic to the concerns, but have a long history of being troubled
>> by renaming, so I'm trying to ask for explanations of what the real
>> problems are (the cause for needing profile migration is still unclear)
>> to find a way that works for users without unwarranted churn.
>> I think we need a concrete plan on the table that addresses the various
>> situations, including:
>> what happens when there is a new release called ESR, in terms of
>> updating firefox and firefox-ESR (I sent one earlier - is that the
>> right plan?)
>> what do we do about superceded ESR releases (rename to firefoxNN, if
>> there is a reason to keep it, but in general do not keep?)
>> are we in general not going to keep old things that are non-ESR? (I
>> am guessing 52 was ESR) It seems best to have a plan to have the
>> minimal number of extra versions.
>> and related:
>> Why are we keeping 60 still, and how do we get rid of superceded ESR
> Extended Support Releases are a continuation of some previous mainline
> version. Go back in VCS history and pull up the version they're derived
> from, and the patches and build machinery might be useful, assuming
> everything appplies. www/firefox-esr gets updated to that newest release
> blessed as ESR, with that stuff hopefully being helpful for updating it.
> The first version of www/firefox68 in-tree was 68.1.0.
> The last version of www/firefox with major version 68 was 68.0.1.
> When the next version of SeaMonkey is available, it will be based on
> Firefox 60 (probably), and the build machinery and patches from 60 might
> be useful. But they can be pulled from the attic.
Yes, but I was looking for a set of rules that will describe the new way
of updating. Without that written down, we can't decide if it's a good
idea. Points missing explanation are
what happens when esr version and current version match
what do we do about superceded versions (e.g., like 60, presumably,
which we still have)
>>but in general do not keep?
> Yeah, I don't think we can afford to have too many firefoxes in tree.
> Or thunderbirds, for that matter.
> There isn't the people to keep them working (never mind safe to use),
> and they're extra wasted electricity for the bulk build boxes.
> I don't think there will be another 52, unless they really mess up.
> The Rust situation will probably get better with time.
> I upstreamed some RNG fixes recently!
That all sounds good. We already have 4 which is too many, but that's
life with an unstable upstream.
Main Index |
Thread Index |