Nilesh Patra <[email protected]> writes: >> What would the best action be -- file a 'serious' bug to trigger testing >> removal, and possibly offer a place to discuss the package? And after >> some months after testing removal, ask for ftp-master removal to cover >> unstable too? Maybe the last step is not essential, but having ancient >> unused packages in unstable is a QA concern. > > I'd suggest directly doing a ROM (and X-Debbugs-CC the Uploaders) as > this saves us the work from having to do the manual work of tracking > those serious bugs and later reassigning them.
Yeah, I'm inclined to do that too -- assuming ftp-master doesn't remove
packages which has reverse dependencies in Debian (and we should check
that before filing the bug), I really don't see how that could be
problematic. In the worst case, we can re-ITP a package and upload it
again. The loop to file serious bugs and then wait and later reassign
will just cost more of our QA time.
> I'd guess your script would output go applications as well along with golang-*
> libraries, right?
My intention was the filter those away, presuming they would ship more
than one binary package (a golang-*-dev package and some binary):
"Binary: golang"*)
test -z "$srcpkg" && continue
case $line in
# FIXME ignore multi-binpkg sources for now
*,*) continue;;
esac
However there are false positives (and negatives) hidden in that FIXME.
Let's start with removing single-package golang-*-dev source packages,
there should be plenty to work on there.
/Simon
signature.asc
Description: PGP signature
