I somewhat agree with Yuri on this. I think for the experiments section we should not require code reviews. I think the code reviews have been very helpful for people to collaborate and learn the existing codebase and has kept it from introducing a lot of instabilities. I would note that almost no "real" code commits have been clean right from the get go. During the code reviews we have found a lot of things that needed to be changed.
Pre-reviews force the committer to get the attention of other committers. If you try to do it after the fact, there is less incentive. ~Michael On 6/19/13 9:58 PM, "Yuri Z" <vega...@gmail.com> wrote: >Hi Upayavira >While reviews are not strictly required by Apache, each community has it's >own culture. The decision to pre review or post review is a trade off. >With >pros and cons on each side. >In my opinion we should to continue to pre review each commit for the >following reasons: > > - Each developer has it's own style, which not necessarily complies >with > the style of Wave code. IMHO it is very important to keep the style >uniform > over the whole code base and the standards should be equally high. It >is > easy to let the code quality slip down, but very hard to bring it back. > - Wave code is sometimes complex with many layers of abstractions, >which > means that's it is easy to break something but hard to fix. > - Absence of code reviews can hinder adoption of Wave by > big/governmental organizations that want each line of code to be >reviewed > by community to reduce the risks of malicious code planted into the >code > base. > - Code reviews force open and constructive discussions, which allows to > to keep the community consensus over the ways the product develops. > > > >On Thu, Jun 20, 2013 at 4:02 AM, Upayavira <u...@odoko.co.uk> wrote: > >> >> >> On Wed, Jun 19, 2013, at 03:00 PM, Christian Grobmeier wrote: >> > Hi all, >> > >> > from time to time I see in several projects the term "lead developer" >> > coming up. Sometimes incubating projects are confused also when to >> > grant committership. >> > >> > On the "lead developer": the ASF is a do-cracy, as we sometimes say. >> > The guy who "does things" is actually leading it. We do not have a >> > hierarchy, like a senior programmer who tells juniors what to do. The >> > whole project is "leading" the project. There are no real managers or >> > something like that. The term "lead" does let "non-leads" wait before >> > they are taking action. But in fact, everybody reading this list is >> > invited to take initiative and do things. Even non-committers can >> > "lead" something. >> > >> > When a non-committer has show commitment to a project, he gets >> > invited. Projects have different bars for inviting people. Personally >> > I always prefer to set a pretty low bar for earning committership. >> > Becoming a PMC member is a different thing. The bar should be higher. >> > For example, I think about a candidate if he is around for lets say 3 >> > months and contributes. Contributions can be answering user questions, >> > writing docs, cleaning up Jira, writing code and so on. Translators, >> > Community people, they all can become committer. >> > After three months it is clear if the person wants to stay around or >>not. >> > >> > The PMC should then open a [DISCUSS] thread on private and speaking >> > about the candidate. He should fit to the team. Toxic people can be >> > dangerous. >> > >> > You are project are free to choose when it is time to invite a person. >> > >> > In the current situation as Incubator podling I would even have a >> > lesser bar. In the situation of Wave - complex technology driven by >> > less people with less time - the bar should be very low. But this is >> > just my opinion. If you agree, work through the mailinglists and >> > nominate people. >> > >> > In general, it needs to be easy to contribute to Wave right now. >> > Complex review processes might stop people. I cite Upayavira in the >> > hope this thread is more visible: >> > >> > "= review then commit = >> > Mature communities usually follow this, when there's substantial risk >>in >> > making chances. Wave is way to young for this, IMO. >> > >> > = commit then review = >> > This is what I'm used to. Make a commit, and have other developers >>watch >> > the commit list. They can object on the dev list if they see something >> > they don't like, but the basic assumption is that, if you have commit >> > rights, we trust you." >> > >> > I am also a fan of ctr. I agree that Wave is ways to young for rtc. >> > Instead, code base must move on as quickly as possible. >> > >> > Please see this e-mail as suggestion, and not binding. >> > >> > I want to make sure: >> > >> > - non-committers know they are invited to perform actions >> > - committers know its ok to early invite new people to the project >> > (don't be shy) >> > - there is the option to commit-then-review - no need for a review >> > board in early stages, if you ask me >> >> No need for reviewboard because that's what the commit mails are for. If >> you are a committer, make sure you are receiving them and do review >> them. >> >> Upayavira >>
