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

Re: Flagging upstream dead software (Was: DICOM viewers)



Le Mon, Aug 02, 2010 at 10:51:10AM +0200, Andreas Tille a écrit :
> 
>   1. Where to store the information?
> 
> 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).

Hi Andreas,

I think that debian/upstream-metadata.yaml would be a nice place indeed,
as it allows to update the package's status without uploading a new
source package. I can not promise to succeed given my low level in python
programming, but I will try to have a look again at UDD integration this
week-end.

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


In the cases where heuristics can provide an automated answer, I suggest that
we do not document the status manually. For instance if a package is not
updaded between two Debian releases, when a watch file that was functionnal in
the past stops working for a long time, when the upstream VCS had no commits
for years, or when the upstream contact address is unreachable. That would also
simplify the semantics, so we could have for instance ‘Abandonned: <URL public
message>’. Otherwise, we could have a more free-form field in which to document
the upstream status, for instance: ‘Inactive: Abandonned’, ‘Inactive:
unreachable’, ‘Inactive: not-downloadable’,…

I think that I would rather favor a simple ‘Abandonned’ field: the more complex
is the documentation we propose, the less documentation we will have. But the
problem is that people rarely abandon their software in public. Perhaps we
could have a more relaxed definition, where the URL points either at a public
upstream message, or at a thread started by the package maintainer, in which
the future of the software is discussed with Upstream being in the To: or CC:
recipient fields, and that ends with no response from Upstream.


As a side note, ‘dead upstream’ is quite casual, and I am worried that in some
situations it may hurt. We do not know the reasons why upstream authors stop
maintaining their packages; sometimes it can be that they are very sick for
instance. I suggest to use a more factual name in whichever system records
their activity, for instance ‘inactive upstream’.


Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


Reply to: