Re: Release sprint results - team changes, auto-rm and arch status

[Niels Thykier <niels@thykier.net>]

On 2013-11-29 04:14, Steve Langasek wrote:
> Hi Niels,
> 

Hi Steve,

Sorry for the long overdue answer,

> On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote:
>> kFreeBSD was a technology preview, and has not generated enough user
>> interest to bring in sufficient install base to continue in this
>> state.
> 
> I wonder, how is the release team measuring this?  For the other ports that
> you mention, you've pointed to concrete technical problems that are in line
> with the previously-documented release qualification guidelines.  kfreebsd,
> OTOH, is only listed as having "insufficient install base".  But what is
> sufficient?  http://popcon.debian.org/ shows numbers for kfreebsd-* that are
> greater than a number of our ports.
> 

The formulation is very poor indeed.  What we are concerned about is
that kFreeBSD basically have not improved since it became a "technical
preview".  There is a related mailing thread only on d-release[1]


> You rightly point out that keeping the architectures in testing has a cost,
> because the architectures will block testing migration.  But are the
> kfreebsd archs actually causing testing blockages, in practice?  If there
> are such blockages, can you give us more information about how this has been
> the case?
> 
> Cheers,
> 

I have been seeing quite a few packages FTBFS on kFreeBSD being stuck in
sid with fixes for RC bugs in testing.  Of course, this problem is by no
means exclusive to kFreeBSD - other architectures (sometimes, even i386
or amd64) also "features" on that list of blockers.
  The only purely factual data I got currently, is the little snippet at
the bottom of Britney's log.  I am not sure how reliable it is, so I'll
refrain from using it as an argument.  But I think we (i.e. the
distribution) could do with an accurate data source on this topic!

On a related note, I suspect a good part of this problem would go away
if we had an automated tool to deal with the case where a (sid-only)
FTBFS is ignored.  It happens sometimes that the maintainer does nothing
(or, maybe, does not realise the package FTBFS on arch X) and neither
the porters nor the buildd admins filed a bug for it.
  Then it is not until the package gets in way of a transition (or some
other RC bug fix), that the package gets its RC bug.  I have seen a
package stuck in sid for at least 90 days and still no RC bug - the
"only" thing wrong was an "Out of date binaries" on some architecture
(don't remember which package nor which architecture).

~Niels

[1] https://lists.debian.org/debian-release/2013/12/msg00416.html