On Sun, 19 Dec 2010 15:01:30 +0100 Albin Tonnerre <[email protected]> said:
> On Sun, 19 Dec 2010 22:14 +0900, Carsten Haitzler wrote : > > On Sun, 19 Dec 2010 10:28:20 +0100 Albin Tonnerre <[email protected]> said: > > > > > On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : > > > > tests are for developpers, not packagers > > > > > > That is terribly wrong. Packagers care about testsuites for one simple > > > reason: as thoroughly as developers may be testing the code, that will > > > never guarantee proper behaviour on the system on which the code is built. > > > > > > When creating packages for Debian, I /do/ care about the testsuites > > > because the testsuite not failing is the only reliable thing telling me > > > the lib is not utterly broken on the system it is being built on. > > > > > > I understand users not listening or unwilling to fix the suite to fit > > > their needs is a pain, but let's not make it an even greater pain for > > > people who just want to use it and manage to. Things have improved a lot > > > as far as packaging is concerned in the last months, and this is clearly > > > a step backwards. > > > tests are for developers so when > > they modify code they can check they didn't break anything. packagers can't > > do much with a test suite. > > At the very least, they can notice the testsuite is failing and investigate > possible issues (and report them when/if approriate). that's not what happens. they mail us to have us copy and paste the failure line - ecore_x_init() fails. gee - i wonder what that does? > > does the linux kernel have a test suite that is run > > when people build packages? does xorg have one? i can continue with the > > list. they don't. > > Glibc does have one. GCC has one. And they do find bugs - especially tricky, > architecture-specific ones. which we don't have. we don't do much architecture or os specific stuff (relative to glibc/gcc). what we have is a problem with gentoo packagers seeing a shiny button and then pressing it. moving the button to somewhere outside the src tree means they dont "see" the shiny button. all good. no more pressing of it. i tried the "don't press it then" path. that doesn't work. > > any test suites are part of the development cycle not the packaging > > cycle, but as they are in the sr4c tree, some gentoo devs seem to think that > > they should work as part of their ebuild (which is packaging). this is not > > the case. > > Are you purposedly ignoring my point here? I just explained why those suites > are useful in the process of building packages. And not only to Gentoo devs, > since I've been using them pretty much since they've been around. Besides, > moving them away from src/ is basically making them harder for just about > everyone, not just packagers. yes i am. you explained assuming that 1. we do do tricky architecture things per os/arch (we do very little and the little we do is pretty much all in evas which has a separate test suite.. AND guess what - most of it requires you have a special test environment... like somewhere to display.. and opengl AND opengl-es2 libs AND special versions of the cpu etc. - and even then they don't test and catch everything - or even most things, just some). for developers moving them away is not harder. you check out the whole svn tree - do you not? where packagers (generally) ONLY check out 1 dir OR just use a tarball which is a subset. it makes it easy for devs and hard for packagers as packagers are given subsets of the tree, developers are not. > As bored as you might be by some people's behaviour, this is wrong. I think > you did get your point across fairly clearly, but let's be realistic: you're > not doing anyone - not even yourself - a favour by moving the tests away. have you even looked at the tests? let's just talk about ecore for now. they test almost NOTHING of ecore. they test a tiny tiny tiny tiny tiny bit. they help utterly not at all. as above. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
