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

[Niels Thykier]

On 2014-01-11 23:10, Robert Millan wrote:
> On 11/01/2014 21:32, Niels Thykier wrote:
>>> As for #712848, the latest comment sent by Petr suggested that the test might be
>>> incorrect when applied to kqueue.
>>>
>>
>> I guess you are referring to comment #25 here?  Quote:
>>
>> [...]
>>
>> Seems like no one picked it up from there.  To be honest, I am not sure
>> where the ball is on that bug right now - as an outsider it is not clear
>> to me if Petr is asking for the GNOME maintainers or the BSD porters to
>> follow/second him.  Admittedly, I have very limited knowledge of the
>> code in question, so it may be more obvious to you.
>>   Perhaps you could follow up on the bug and prod the GNOME maintainers
>> for a follow up, if you believe the ball is in their court right now.
> 
> Before we get into that, would it be possible to establish the severity of
> this bug? Specifically, whether it is Release-Critical or not.
> 
> It is currently marked as non-RC, and so far we haven't seen any indication
> that it produces actual breakage (outside the testsuite, that is) [1].
> 

It was filed as serious and then downgraded by Julien on July 9th.
Indeed, buildd.d.o lists no build problems at all.  So at first glance I
would expect the tests to have been disabled/ignored.  Assuming this is
no a simple "error-hiding" tactics, then the bug is non-RC.  If it hides
user-visible errors, then the severity depends on the (consequences of
the) errors hidden.

> However, your comments in this and earlier mails seem to imply that it is
> RC, or that you think it could be.
> 

I had no intention of making such an implication.  From what I gathered
from various sources, glib and GNOME on kFreeBSD had issues and that is
what I am following up on.

> In our experience as porters, we've found that we get lots of testsuite
> failures (and not just in GNOME). However, often the tests just fail because
> they're overzealous, or because they make wrong (unportable) assumptions
> about the underlying APIs.
> 

The assumption here is that the test is indeed overzealous / not
relevant to kFreeBSD and have no value as a regression test on kFreeBSD.
 If that is indeed the case, by all means (have the maintainer) disable
the test on kFreeBSD and close the bug.

The concern from my point of view, is if a valid test is disabled when
it could have been ported.  The last thing I want is to have an RC bug
appear in testing for a problem the regression test suite from upstream
could have caught.


> I believe #628383 would be a good example of what I'm saying. But the problem
> is very typical. It's not uncommon for us to submit fixes for testsuite bugs
> rather than having to fix the bugs the tests are supposed to find.
> 

I believe that is perfectly fine to fix portability issues in the tests
themselves.

> Probably Petr and/or Steven can elaborate more on this, since they've been much
> more actively involved than me in this kind of work.
> 

Ok.

> [1] If the reason it is RC is that it causes FTBFS (and serious buildd grief),
>     I think http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734290#10 is a
>     good solution in that regard.
> 

This particular kind of resolution would concern me.  Simply disabling
all tests and ignoring all problems would undermine any value of the
regression test suite (on non-Linux ports in this case) and allow RC
bugs to migrate to testing before they are noticed.

With my release hat on, I want as many problems stopped before they
reach testing.  Having a build-time regression test suites from upstream
is certainly valuable in this regard and we currently have no
replacement for testing the actual program itself.

~Niels