> -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Thursday, December 20, 2012 9:54 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: Concerns about our community health and collaboration process > > On Thu, Dec 20, 2012 at 12:46 PM, Marcus Sorensen <shadow...@gmail.com> > wrote: > > Thanks for the followup Chip, I think I have a better idea now. > > > > The silence == consent thing is a bit hard for me to take; as a committer I > > have the ability to really screw things up, and so there's a lot of > > potential fallout from moving forward with something only to find out that > > someone missed a conversation. It also sort of validates how we've been > > doing things, if a feature is discussed, but there's little community > > interest, that sort of seems like the go ahead for us to just work on it > > and offer up our solution, with the caveat that the implementation needs > to > > be spelled out in detail so to reduce blowback if some unexpected result > > occurs that was overlooked simply because nobody was really interested in > > the feature when it was being discussed (that worries me too). This sort of > > links back up with Alex's thread about knowing who is a mentor or leader > > over each aspect of the project and understanding who to get buyoff from > > for a new feature. > > > > So I'll add to this - changes aren't set in stone after a discussion > period or commit. The magic of version control essentially lets us > revisit decisions - at least before release. For instance - Alex just > called out a problem with an upgrade script - and that was committed > well over a week ago, and I expect it will be fixed before release. >
Things are not always that simple. Not to pick on Wido here but it happens to be the example I remember. In 4.0, he changed the build. Everything looked good but it only worked on Ubuntu. By the time we caught it practically the whole system was already on it and further changes were piled on. We were caught between fixing it or back everything up. And it took a week to fix it for other environments. I generally believe we should code review before it actually got committed to the branch. The things I like to code review are interfaces and any sort of contracts. Bugs in implementation will generally be found. However, problems in design generally leads to nightmares later and they're usually not found until much too late. --Alex
