On Fri, 4 Feb 2011, Raphael Kubo da Costa wrote:
> Vincent Torri <[email protected]> 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. As I said in an answer in that thread, we can add exceptions. Using that kind of policy on some specific libraries (Evas, Ecore and Edje as they are maybe the most important ones) could be good for code solidity. But for example, maybe we can let Tom doing his text job on evas and edje without such review. 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
