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. What I meant is that those guidelines apply on both patches and commits, no matter if you have access or don't. And that's what I disagreed upon in your email (and many others as well). When I mentioned the email, I was only talking about submitters.
> again, with moap, you have both the ChageLog and svn log at the same time > (see Epdf or Evil, their ChangeLog and commit messages for example) > > But I guess that it can be done manually of course. Is there some tool > integrated in svn that can do that automatically ? No idea. But you don't always want to update the changelog (on every commit). I don't mind using tools, and I don't mind suggesting people to use them, but it's important to let people the possibility to avoid them. Exactly like the usage of git patches in the ML. > just checking it can be applied, can be compiled, checking formatting, > changelog being updated is alread good, so yes, other people than > developpers who can review the validity of the code could help. Yep, my point exactly. > I would prefer a specific ML for patches so that the edev ML is not > polluated I think you are right about polluting edevelop, it annoys me too, but I think that keeping patches here will mean more people will casually review patches. > that can be done by setting them in configure.ac, if the 'rev' version is > not 0. I already said I like that. Raster doesn't so we can just tell people to set their cflags. > > reverting a patch is, for me, a necessity (if the comit is not good > enough), to have good code in svn. I agree. > I can but agree as I want to be stricter, as I already said. Rome was not built in a day. > > And about being the bad-man, in case you didn't remarked, I was here > before you with my 2 mails about changelog and commit policies. I can > continue to be evil I know you are stricter than me and since you aren't on IRC lately you didn't see I refer to you as the evil one :P Let me rephrase: "I'm willing to be vtorri's evil right hand." I'm glad we mostly agree, and if (when) these guidelines will prove themselves we'll suggest a stricter set of guidelines. -- 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
