KDE SC 4.11 Release Schedule

[Christian Mollekopf]

On Saturday 19 January 2013 19.06:52 Martin Gräßlin wrote:
> On Saturday 19 January 2013 18:19:03 Albert Astals Cid wrote:
> > El Divendres, 18 de gener de 2013, a les 18:58:07, Martin Gräßlin va
> 
> escriure:
> > > On Tuesday 15 January 2013 23:27:53 Albert Astals Cid wrote:
> > > > 4) Don't release if any if the tests are failing in builds.kde.org
> > > > 
> > > > 	If we have tests, they have to work
> > > 
> > > I have mixed feelings about that. Personally I agree completely, but I
> > > fear
> > > that this will end in less unit tests than in more. If you have unit
> > > tests
> > > and they have been broken for a long time you get punished,
> > 
> > Right, but why would you have a broken unit test? The only reason i can
> > think of is that you know your code is broken but don't have time, etc to
> > fix it yet. If that's the case i'd suggest using QEXPECT_FAIL maybe?
> 
> my code works :-)
> 
> I actually had a look into two of the three failing tests and wanted to fix
> them. But did not understand the foreign code base good enough to
> investigate it properly. So I don't know whether this is an expected fail
> (given the commit message which introduced the tests which are failing I
> doubt it) or not. Those two are at least failing since I started looking at
> build.kde.org. Probably nobody cares :-(
> 
> For the third test I informed the maintainer that it started to fail.

I think for those cases we would just need some KKNOWN_BROKEN_TEST or so...

IMO enforcing that there are no unknown broken tests is a good idea, but we 
shouldn't make it unnecessarily hard to maintain tests by placing extra 
hurdles, so such a macro would be a good middleway I think. At least it makes 
it clear for other dev's if a test is supposed to work or not.

Cheers,
Christian

> 
> --
> Martin Gräßlin