Re: www/firefox-esr instead of www/firefox[0-9]*

[Greg Troxel <gdt%lexort.com@localhost>]

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
>>   versions?
>
> 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.