Re: CVS commit: pkgsrc/chat/jabberd

[Leonardo Taccari <leot%NetBSD.org@localhost>]

Greg Troxel writes:
> [...]
> Well, that's how it is -- upstream is not active; they are not
> publishing releases, they are not publishing EOL announcements.
> Everybody knows this about this particular package, and it's been
> discussed before, in 2015, when someone asked that it not be deleted.  I
> merely noted this non-maintenance fact in DESCR, and you said it should
> be in eol-packages!
>
> When you say "discuss about it", do you mean to verify that there is
> consensus that "foo is not maintained any more" is true?  Or something else?
>
> Should I take it out of eol-packages and pkg-vulnerabilities, if there
> is no eol announcement?  I am really finding this situation not well
> grounded in rules that can be expressed clearly and followed.
>

I was discussing in general and I think that for jabberd was gracefully
handled (some users still needed in 2015 but upstream seemed no longer
active for several years).

Regarding possible rules, I do not recall any of them and what I have
said was based on how eol-packages was used in the last years (I think a
similar case of jabberd were rxvt and mrxvt).  Maybe it is worth
discussing that on tech-pkg@ so a consensus or clarifications can be
reached.

>
> It's still entirely unclear:
>
> # -  eol date: date when upstream stopped to support the package
>
> stopping support is not well defined.  Suppose 1.0 is published on
> January 1, 2000 after a series of 0.9x for years, and then upstream
> never does anything about the package ever again.  No new releases, no
> eol announcement, no answering email.
>
> So when did they "stop"?   When do we add it?
>

This seems to be the situation described above: upstream no longer
maintining the software.  Based on mrxvt and rxvt I would add the
current date.  (But there are also entries with no `eol date')

> #  - URL: reference to EOL announcement by upstream or announcement of forks,
> #         de-facto replacements for the package
>
> And when there is no announcement from upstream and no fork, there is
> only the questtion of "what might you used instead", and that has a
> large amount of baggage.
>
>
> The big question is if "eol" is supposed to include "It seems clear that
> this is no longer being maintained, and it's been long enough that
> surely there should have been a point release with bugfixes.  Therefore
> we conclude that there is no functioning upstream."  I would think so,
> but the emphasis on announcements by upstream argues against this
> interpretation.

I think so too but without any announcements or community consensus
it is not obvious if a package is "eol" or not (I'm talking in general,
not regarding jabberd).