On Wed, 2011-02-09 at 16:54 +0100, Vincent Torri wrote: > > On Wed, 9 Feb 2011, Tom Hacohen wrote: > > > On Wed, 2011-02-09 at 16:19 +0100, Vincent Torri wrote: > >> That's what I proposed with the patch ML and you said you didn't agree... > >> as a lot of other people who are now thinking that your idea is good. > >> > > I think you misunderstood me. I don't think core developers should send > > their patches to the ML. > > cedric broke a mempool (i already discussed with tha at FOSDEM, btw) > seb broke efreet > nash broke evas compilation > > I still think that sending a patch to just see if it compiles, has no > problem with formatting and changelog, and testing a bit with valgrind or > other tool, could have avoided such problem. They should be spanked. They should have tested them with the default compilation options (they have?) and also run through valgrind. People sometimes break things, nothing we ever do will avoid that and only QA from all the guys using SVN code will. I don't have the time to start reviewing other developer's commits, and I bet other people don't as well, the only thing forcing our developers to send patches will do is slow everything down and let us blame two people instead of just one.
> > I already said I like that. Raster doesn't so we can just tell people to > > set their cflags. > > indeed. But raster himself doesn't set his flags correctly. Does he use > the warning flag to see if shadow variables are used, or if we do pointer > arithmetic on void ? Afaik, we fixed all the warnings with the latter (i > already discussed about that with him and he was sure that -Wextra > included such warning flag, but it is not the case), but there are plenty > of shadow variable warnings. Once we all agree on the rules (including him) we'll all comply to them. TBH, I was also sure (until you both talked about it) that it was in Wextra :) Anyhow, we currently don't have a set of recommended flags. -- Tom. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
