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 -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100803003516.gb11...@merveille.plessy.net
