Re: mass-removing packages that missed both jessie and stretch?
On 20/07/17 at 11:00 +1000, Paul Wise wrote:
> On Thu, Jul 20, 2017 at 7:29 AM, Lucas Nussbaum wrote:
> > It is becoming increasingly painful to do QA work due to the number of
> > packages in unstable that have been completely broken for a long time.
>
> Could you detail what the pain points are for archive rebuilds?
There are three main problems:
- loss of (CPU) time rebuilding packages that are completely broken
anyway, but that's a minor issue.
- some of those packages are affected by strange bugs that cause random
failures or build hangs
- I keep track of past failures, to avoid filing bugs twice. but from
time to time, I need to start with a clean list. Currently, that means
looking at 653 build failures.
> > I've been pondering with ignoring packages not in testing when doing
> > archive rebuilds, but that's not really a good solution.
>
> Could you detail why ignoring packages not in testing is not a solution?
it would solve the problem for me but:
- it would make it more unlikely to detect problems in new packages
early, because the package would first have to migrate to testing to
be tested
- I'm assuming that everybody doing QA work is running into those broken
packages
> > Here is a list, with the popcon insts, and the last upload:
>
> Some of these were removed due to bugs that are only a problem in
> certain situations.
... but were still considered grave enough by the release team not to be
included in neither jessie nor stretch.
> Some of these are related to a specific blend/team packages and might
> warrant a separate ping to the relevant discussion lists, I expect
> that few folks read the team lists in Maintainer fields any more.
can you give specific examples?
> Some of these have solutions.
... but nobody cared enough to implement them over the last 2.5 years.
> Some of these are for important areas like mobile.
>
can you give specific examples?
I think that the bottom line is: can we draw a line that allows us to
identify packages that are no longer suitable for unstable?
Or should we just accept that unstable has become a staging area where
all broken packages are welcomed, even if there is no interest no hope
to see them again in a stable release? I think we should avoid "once in
unstable, forever in unstable" to become an official motto. ;)
Lucas
Reply to: