Hi, On Fri, Feb 4, 2011 at 10: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 ?
I fear this will introduce to much burden and slow down the process, if for every small patch we need to pass it the patch ML before having the right to commit a fix. I have currently no better proposal, but slowing the speed of development is not really a nice side effect. I know as I often forgot to update Eet ChangeLog, that's it's really not that easy to always remember that, but I don't think slowing down the development is a good answer to that problem. -- Cedric BAIL ------------------------------------------------------------------------------ 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
