Restoring seamonkey

[Mikhail T.]

On 28.03.20 20:47, Jan Beich wrote:
> Lack of the homework.

I really don't understand this, Jan... Let's replay:

 1. I wanted to install Seamonkey on a system I'm dressing up, and
    found, that the port is no longer available.
 2. I looked for the final commit-message, and found:
     1. it was deleted by you, last year;
     2. it was deleted for lack of updates.
 3. So, I looked at the upstream's site, and found, that they've made
    several releases since then, most recent -- last month.
 4. I then wrote you an e-mail inquiring, if the port can be restored...

Do the 2. and the 3. not qualify as "homework"? What more should I have 
done before approaching you for comment?

> Patches do the talking better.
So, you're angry at me for not doing the work, which you're trying to 
dissuade me from doing in the first place?

> According to SeaMonkey 2.53.1 release notes the engine was updated to
> Firefox 60.2ser with security fixes up to Firefox 72. Current version of
> Firefox is 74 while 75 is expected next week. Finding applicable
> vulnerabilities requires checking the code e.g., trying every fix
> against SeaMonkey tree but assuming some rebase churn.

So, your earlier statement about it still being vulnerable is not based 
on any such research, and cannot be substantiated?..

I guess, the port really can be restored...

>>> I'm only opposed on using Mk/bsd.gecko.mk and having gecko@ as the maintainer.
>> I understand the latter, but not the former. As long as gecko@ are not
>> responsible for it, what's wrong with still using bsd.gecko.mk?
> portmgr@ expects ports/ to not break ports maintained by others. Being
> forced to test and avoid breaking bsd.gecko.mk consumers that I don't
> maintain is exhausting.
I understand, what you mean, but do not accept this reasoning. Imagine 
sed-, sh-, or awk-maintainers taking the same attitude, for example... 
It is part of FreeBSD -- everyone can use it.
> Besides, the file has been planned for removal for months/years due to unnecessarily complicating maintenance.
This is a much better reason...
> See www/cliqz for an example of a Firefox fork that doesn't use bsd.gecko.mk.
Thanks for the pointer, never heard of cliqz before -- will definitely 
check out both the browser itself and the port.

Yours,

    -mi