El Dilluns, 21 de gener de 2013, a les 20:36:48, Christian Mollekopf va escriure: > 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...
Isn't that what QEXPECT_FAIL is for? Cheers, Albert > > 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 > > _______________________________________________ > release-team mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/release-team _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
