[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Flagging upstream dead software (Was: DICOM viewers)


[I try to widen the discussion to debian-qa for a more general solution]

On Sat, Jul 31, 2010 at 12:48:40AM +0200, Karsten Hilbert wrote:
> > BTW, this fact lets me think about adding an
> > 
> >    DeadUpstream: yes
> > 
> > field for the tasks files.  We have some of such packages and it might
> > be some interesting information which could be rendered on the web
> > sentinel.  What do you think?
> Sounds useful to me.

Thinking twice about this it makes not really sense to do the flagging
of upstream dead software only for those packages which by chance are
interesting for a specific Blend.  It would be rather interesting to
know this for Debian in general.  There are two items to discuss.

  1. Where to store the information?
  2. How to *define* DeadUpstream?

For the location I see two places: debian/control or
debian/upstream-metadata.yaml.  Past experiences show that the
acceptance for additional fields in debian/control is not very high and
this is probably for a reason.  Moreover upstream-metadata.yaml is
intended to provide information about upstream and thus the information
is perfectly right here.  However, this file does not seem to be widely
accepted (and seems to be only used by Debian Med team members).  Perhaps
this would be a chance to help this file coming out of its niche.  It
would also give me some motivation to finally push the information in
this file into UDD (some code was written by Charles Plessy and waits
for final implementation into UDD).

How to *defines* DeadUpstream?

This part might need some discussion and more or less depends from the
maintainer who is maintaining the package.  Sometimes "no new upstream
version since two years" might be perfectly in line with some projects
release policy in other cases the project can be considered orphaned /
dead.  A missing upstream source at the watch file location also does
not seem to be a safe guess because the project might have moved.

But there are quite safe criterions like: Non of the authors of the
software is responding to three e-mail pings in a row or something like

What do you think?

Kind regards



Reply to: