On Fri, 4 Feb 2011, Cedric BAIL wrote:
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.
Well, on the other hand, see what has been done with efreet : Seb commits,
raster has a problem with the patch, hop revert, then commit, then revert
etc... It's also slows down the process.
Or with the chained mempool patch you did.
And a small (i think it's a small one) slow down for a project that took
10 years to be released... :)
I think that there will be a small slow down because it's only for the
core EFL (eet, embryo, eina : not much stuff to do on them, same for
ecore or e_dbus)
The exceptions: Windows and Mac OS X stuff as they are actually not in a
perfect shape at all. Maybe we can add some other exceptions
Vincent
------------------------------------------------------------------------------
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
