Re: CVS commit: pkgsrc/chat/jabberd

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

Leonardo Taccari <leot%NetBSD.org@localhost> writes:

> 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).

ok

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

I don't think we need to discuss it.  I think you can write a
description of what we ought to do and probably nobody would object.  It
just has to be clear (and not make assumptions that aren't true).
>> 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')

Not quite: it's that we decided that they are no longer maintaining it,
some time after they "stopped".  The problem is that the definition
given posits that it is a reasonable and clear concept that somebody who
on a good day sporadically issues releases no longer does so, and that
there is a particular date associated with this "no longer".

If you want to say:

>> # -  eol date: if upstream makes an announcement that they are no
>>      longer maintaining the software, then either the day after
>>      support ends, or the announcement date if no date is given.  If
>>      pkgsrc decides (in hindsight) that maintenance  has stopped
>>      because it has been excessively long since a release, the date
>>      should be the date that the entry is added.

That's fine.  We don't seem to be converging so I'll just put that in.

> 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).

Actual eol-ness (in the non declared case) can never be actually known;
a release of jabberd14 could come out tomorrow.   So this is very much a
belief/estimate that the odds of future maintenance are very low.
Sometimes eol-ness is obviously false, sometimes it's obviously true,
and sometimes it's messy.  Last release in 2007 makes it obviously true;
if someone were adding an eol entry for something with a last release 2y
ago, I'd say we need more evidence.

The big point is that I'm separating:

  1) how do we as pkgsrc come to consensus that we believe a package is eol

  2) once we have decided it is eol, what do we record and how

I think we genuinely do not have a lot of problems with point 1, and if
a maintainer of a package or someone who is paying attention decides
that upstream is not longer believable as maintaining, that's fine and
we don't necessarily need discussion.  If it turns out that's wrong it's
easy to fix by removing the entries.

Actually removing packages is something else, because that causes users
to no longer be able to use them.  So that needs a deletion proposal on
pkgsrc-users.