Vincent Torri <vto...@univ-evry.fr> writes: > Hey, > > 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 ?
Doing it WebKit-style (every single byte change needs a bug report with a patch + ChangeLog entry + reviewer etc) might be too overkill, even though that might deliver the best results quality-wise. This also implies there are enough reviewers for everything. Do you think an intermediate solution would have a chance? Like creating the patch ML (and optionally using some tool like ReviewBoard) and everything else, but not enforcing its use for every single change (it'd be good if ChangeLog-worthy commits passed through it first, though). The primary con is that sending a patch to the list would be at the discretion of the committer. -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
