On Wed, 15 Sep 2010 09:36:55 +0900 Mike McCormack <mj.mccorm...@samsung.com> said:
> On 09/15/2010 09:13 AM, Carsten Haitzler (The Rasterman) wrote: > > > i do - because i actually do have some level of patches that end up in > > queues (for people without svn access) and they eat up quite a bit of time. > > even for the few that are around and even for fairly superficial review. > > Big patches are bad, you should reject them. If you encourage people to > submit patch sequences, the review load should be much lighter. e.g. (PATCH > 1-10/10) > > You're also assuming that you have to do the review. If you don't have time, > why not appoint/request somebody else to do it? doesn't matter if it's me or not - if it was me, i'd never have written a line of code over the past 10 years. i'd have purely reviewed. i'd still be behind. as such if it was spread around it'd still heavily impact development. but i do agree with the "small patches". i disagree with needing to go into a patch queue and be reviewed. i think we can handle this given our current infra with svn commits list - the commits though need to be small and digestible. instead of committing 1 month worth of work in 1 big commit, it's split into small bits as you go - first with base infra (disabled), then u fill it in a bit piece by piece etc. and slowly it appears and eventually is actually vaguely usable - people try it out and maybe comment on your design and code at the time - maybe spank you, and eventually it all comes together and is on by default and is now used and it gets much heavier testing. as such e3 and e4 (our 2 new french servers) are intended to become build and test machines - they literally will rebuild large chunks of svn and create reports etc. they are not ready yet. being worked on. > >>> review doesn't just magically catch all bugs. > >> It magically catches 80% of bugs, which is a good start. > >> > >> How about having patches at least verified by a buildbot before they're > >> commited? > > > > that's the job of the committer to at least have built the src first and run > > and tested it. if devs consistently commit patches that dont even build or > > work in the most basic way then they probably should have svn access > > revoked. this isnt a technical issue - it's a human issue. to be solved the > > human way - spank them a few times and eventually kick them out. > > Everybody makes mistakes. Having at least a basic sanity check on what's > committed would improve the quality of SVN quite a bit IMO. > > I'm wonder if there's any other successful projects out there that have 50+ > commiters, and zero review of patches before they go in... i suspect there definitely are :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
