Re: CVS commit: pkgsrc/chat/jabberd

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

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

> Greg Troxel writes:
>> Leonardo Taccari <leot%NetBSD.org@localhost> writes:
>>
>> >> On this subject, eol-packages is ambiguous on a few points:
>> >>
>> >>   There is a date field.  What's this for, and what does it mean?
>> >>
>> >>     - Is it the date the entry was added?  (If so, why is this useful?)
>> >>
>> >>     - Is it the date that the package was declared eol by the upstream?
>> >>
>> >>     - Is it the date that we decided, perhaps in retrospect, that
>> >>       upstream is no longer functioning?  If so, is there a norm for how
>> >>       and when to decide.  (Clearly 12 years is enough; it's 4 that's
>> >>       hard.)
>> >
>> > It is the date that the package was declared eol by the upstream (the
>> > first example commented out is confusing).
>>
>> Then probably that should be stated in the file.  Also, it should be
>> explained what to do when upstream has not made an eol declaration.
>> Perhaps the package should not be listed here in that case.  Then, we
>> need an approach for packages where upstream doesn't seem to be
>> maintaining the package, but has not declared it eol.
>
> I think that when there isn't an official EOL announcement from
> upstream and they are no longer easily reachable it would be better to
> discuss about it in pkgsrc-users@ case by case, similarly to what it is
> done for package removals.

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.


>> >>   There is a "URL" field.  It's clear in the case of a functioning
>> >>   upstream that deprecates a branch, for which we have a multi-version
>> >>   package.  For an upstream that just sort of stops, it's quite unclear
>> >>   what if anything belongs here.
>> >> [...]
>> >
>> > In these cases, URL with announcement about possible forks, possible
>> > de-facto replacements or similar could be helpful (a couple of entries
>> > also don't have any URL field at all in that case).
>>
>> OK - perhaps you can edit eol-packages to explain this.
>
> I have replaced the example with a description for each fields.
> Please let me know if there is still something unclear or please
> directly improve them.

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?

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