A stable master is very important for new contributors to feel welcomed. This also saves lot of time for devs who work on acs. We do not have good test coverage (and we do not have infra to even run the existing tests against real hardware and hypervisors). Once we have that, we can accept anything that passes tests. Until then, I think manual reviews is the only way.
There used to be long queues and abandoned prs/reviews even before. I think the current process is more time consuming for existing committers( than new contributors) who used to directly checkin. But, it is definitely better for committers to get their code reviewed than to wakeup to a broken master. ~Rajani Sent from my Windows Phone ________________________________ From: Wido den Hollander<mailto:w...@widodh.nl> Sent: 26-08-2015 19:36 To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> Subject: Re: [DISCUSS] Improving community experience for (new) contributors On 08/26/2015 03:53 PM, Remi Bergsma wrote: > Hi Rohit, > > Thanks for sharing your observations. I agree with you that anybody that > contributes (or uses) Apache CloudStack should feel welcome in the community. > > In the past weeks I tried to respond to as many PRs as I could and merge them > as soon as it met the requirements. When I can not review myself, I usually > ping someone and ask to do the review. This way I hope new contributors too > get a fast response. I agree this is important so let us all have a look at > the PRs on a regular basis and review them if possible. > > Also, I dropped the closing of PRs for now. I get your point and propose to > leave it as-is. It’s not important now. > > I see a master that gets more stable every day and I think that’s awesome. > Also for new contributors or new users this is great, as most new devs will > checkout master to see if it is any good. In the current state, I’d say we > improved greatly. > And that's something that makes me happy. In the past we had tons of broken code coming into master which made development against master painful. Very painful. We indeed slow development down now, but I think that is a good thing at this point. We need to stabilize a lot. > So, it’s true that our review process takes time and effort, but IMHO it’s > worth it. Running tests before anything hits master shows us problems in > advance. And in case it doesn’t, we can always go ahead and improve the tests. > +1 I don't say it's perfect now, but it's better then it was. > If you see things we can improve, please share. > > Regards, > Remi > > >> On 26 Aug 2015, at 12:20, Rohit Yadav <bhais...@apache.org> wrote: >> >> Hi all, >> >> I’ve identified few issues around the recent changes that I don’t know >> how we can fix or improve but I hope to get feedback from the >> community. >> >> I understand that you may disagree with what I’m sharing which is >> alright, even in your disagreement I hope that you don’t take an >> offence on that, that is certainly not my aim. I personally want to >> the community to be felt welcoming so that we can attract and retain >> new contributors and have a nice environment for everyone. >> >> Some observations and comments: >> >> - Generally those of us who have worked for long in the community or >> have colleagues from dayjob working in the ACS community - we have >> better chances in getting their PRs merged; for new contributors this >> pattern is not encouraging and certainly not welcoming if their PRs >> get closed. >> >> - The recent drive to use Github PRs seems to be really working great >> for us, but still the requirements of at least 2 +1s/LGTM, unit tests >> and pedantic bike-shedding has cost us new developers/contributors and >> kills the joy of programming for some; for experienced and >> commercially backed developers this makes sense. I personally try to >> be pragmatic and lenient on code reviews as long as smoke tests >> (Travis) pass. >> >> - Contributions are process-oriented that cost time and effort; there >> have been initiative to satisfy the tool but not the human, and not >> optimizing on developer time. >> >> - What should we do to get more developer contributors and how to >> attract hobbyists or casual contributors. >> >> Regards. >
