Re: feedback for NEW packages: switch to using the BTS?

[Don Armstrong]

On Sat, 30 Apr 2022, Paul Wise wrote:
> I suppose debbugs could allow the package state to go out of sync with
> NEW and instead retain the addresses for a certain period of time
> after packages are removed from NEW and while there are open bugs on
> the packages that were removed from NEW. 

This might be a reasonable process to figure out. We currently don't
disambiguate between "this package never existed" and "this package used
to exist".

Doing that would allow the current FTP master process to work while
tracking things in the BTS.

REJECT process would create a bug against the source package which can
be optionally cloned by the maintainer if they want to fix issues
separately.

Packages uploaded to NEW would create entries in the to-be-created
"historical Maintainers" file. We wouldn't bother to track detailed
versioning information; that will get fixed up when the package actually
transits is ACCEPTED.

Still unresolved is how this intersects with the search that people use
to reassign bugs against outdated packages to the current package (or
close bugs in removed packages).

-- 
Don Armstrong  https://www.donarmstrong.com

Grimble left his mother in the food store and went to the launderette
and watched the clothes go round. It was a bit like color television
only with less plot.
 -- Clement Freud _Grimble_

Re: How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Andreas Tille (2022-03-21 11:55:09)
> Am Sat, Mar 19, 2022 at 08:37:28PM +0100 schrieb Erik Schanze:
> > Am 16.03.22 um 14:11 schrieb Andreas Tille:
> > > was not uploaded by its maintainer for >10 years.
> > 
> > Yes, because upstream development was finished and packaging was working
> > so far. No need for new uploads IMO.
> 
> My point was that there are teams inside Debian (like reprocucible
> builds or crossbuilding like bug #989953) who file bugs with patches to
> a lot of packages.  I personally think we should somehow help them to spent
> their energy on packages that are worth it.

personally, when doing work that affects multiple packages, I concentrate on
those that are in unstable *and* in testing. In my experience this weeds out
99% of those source packages that I really shouldn't bother with. I heard from
others that they use the same heuristic to spend their QA time on packages that
will likely make it into the next stable release.

During my last round of mass-rebuilds I unfortunately didn't apply this
heuristic and stumbled across src:ants. In contrast to Andreas, I think that
even packages without a maintainer upload for >10 years should *not* be kicked
out of the archive even if their popcon numbers are down to zero.

However, I do not understand why we do not have a mechanism to kick out source
packages like src:ants automatically for good. Not because of its low (and
decreasing) popcon number but because:

 - the last stable release the source package was part of, was stretch
 - its binary package was last installable during the development of buster and
   uninstallable since then
 - the source package has four open RC bugs with the *youngest* from four years
   ago

Why do we carry essentially useless weight around for so many years?

Thanks!

cheers, josch

signature.asc
Description: signature