Hello,
I think that the stability of the master (and other living branches) is
(very) important too.
The 2 LGTM requirement can be annoying but if it's permit to have less
(regression) bugs and better stability then we can continue in this way
IMHO.
That said, perhaps we need update this page [1] to indicate the 2 LGTM
process and add to the "ping process", a sentence like "don't hesitate
to ping the dev list, particular if you are new in the community"
[1] http://cloudstack.apache.org/developers.html
Section: "Review
Once you've submitted your pull request, you should receive a response
within a few days. If you receive no response within a week, please ping
the cloudstack-dev mailing list (dev@cloudstack.apache.org)."
Milamber
On 26/08/2015 17:09, Rajani Karuturi wrote:
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.
