On Fri, Feb 4, 2011 at 11:45 AM, Vincent Torri <[email protected]> wrote:
> to be more strict about commits on the core EFL (that is, those that have > been released as 1.0), maybe we could do like other projects: > > * create a patch ML > * never commit directly to svn but send the patch to that ML > * once someone has reviewed the patch, one can commit it (the reviewer > or the original author of the patch if he has commit access). > > This would ensure that: > > * nothing is forgotten (changelog, push to 1.0 branch, formatting, ...) > * patch is tested by another person, so more solid code. > > Cons: a bit slower development process. > > What do you think ? > > Sorry for my late reply, wasn't at home. I disagree with the idea. I agree we need more organization, and it's funny that you just sent this email, because I started writing (a few days ago) a similar email about organization of patches, commits and generally development guidelines for those who have commit and those who don't. Regarding the idea: I'm a bit ambivalent regarding the patch ML, but I do think we need something like patchwork ( http://ozlabs.org/~jk/projects/patchwork/ ) which I like. I don't think everyone should go through the ML, that's just painful and slow, but I don't mind (was about to suggest that in the email) that cross-modules commits will be done through ML, for example, discomfitor is the "maintainer" (we don't have such a definition, but we really need to have) of eeze, I don't think I should be allowed to commit anything there (except for reverts of broken commits, documentation and coding style, and even about those I'm not 100% sure). I don't think people will review each other's every commit and check for formatting errors, and I really want to believe whoever have svn access don't have formatting errors. Regarding pushing to 1.0 branch or updating changelog: we just now did a release after many years, it's understandable some people will forget, but we go through the e-svn ml anyway, and we'll spot such obvious mistakes, no need for per-commit ml for that. I don't think reverting patches is a bad thing, it's a bit more painful in svn (comparing to git), but it still is bearable. "more solid code" is not really a "pro" because when you push to trunk many people (including many users) test it and give you feedback, we (devs and users) are the ultimate QA team. Regarding code review: not everyone are confident enough about some pieces of code to really review them. For example, many times I go through patches to code I don't know very good, and just say something if I have something bad to say, I don't know the code good enough to approve it, so you'll just end up with infinitely long lists of pending patches because as mike said, there are just not enough core devs in e at the moment. In conclusion, it all comes down to a how you trust those with commit access, and if you don't trust them to update changelog/push to 1.0 you shouldn't trust to send to ml before committing. As stated above, people forget just because it's a new policy, after a couple of public spanking people will remember and follow. I will better summarize my other thoughts and ideas in the other email I'll be on Tuesday. -- Tom. ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
