couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: we need more reviews
Date Wed, 22 Jan 2014 14:06:33 GMT
On Wed, Jan 22, 2014 at 12:47 PM, Noah Slater <nslater@apache.org> wrote:

> My first comment is: if we want more reviews, let's have more committers.
>
> We double our committer base in 2013, and the results look like this:
>
>     https://www.ohloh.net/p/couchdb/analyses/latest/languages_summary
>
> And I see comments like this on StackOverflow:
>
>     "I've recently noticed that Couch DB is back in heavy development."


> So I think we should continue to aggressively recruit more committers
> to the project in 2014. Excelsior!
>

Welcoming new committers in the project is certainly a good thing but I
think it's orthogonal to the need of more review and team work. We should
find a good workflow now while we are still a limited number of committers
because It will be harder to enforce anything on a larger team. We should
settle on some guidelines now. It will also help us to attract more people
IMO.


>
> However, as for the way we do reviews...
>
> Infra ticket about Gerrit
> https://issues.apache.org/jira/browse/INFRA-2205
>
> Effort seems to be mothballed. But I'm sure we could restart it if we
> were serious.
>
> However, we could use this:
>
> https://reviews.apache.org/groups/hive/
>
> It is well integrated with Apache infrastructure already, sends mails
> to the mailing list, and so on.
>
> Happy to request an instance and we can experiment with it if we like.
> If it doesn't work out, we stop using it. No harm. Could make it
> entirely voluntary until we figure out a workflow that we all like.
>
> Should I do that?
>

I thought gerrit was already integrated but any tool that could help us to
make the review is OK for me. How hive compares to gerrit? Could we also
plug it with github like gerrit [1] ?

- benoƮt

[1] https://gerrit.googlesource.com/plugins/github/ (and some others)

>
> On 20 January 2014 15:30, Nick North <north.n@gmail.com> wrote:
> > On 20 January 2014 12:26, Dale Harvey <dale@arandomurl.com> wrote:
> >
> >> I fully agree, its something I mentioned at the couchdb conf in
> vancouver,
> >> a review first system encourages contributions and has multiple benefits
> >>
> >>  * At least 2 people look at the code, less likely to push silly
> mistakes
> >>  * Can codify and practice review rules
> >>  * Its much easier to view the current activity in the project
> >>  * Can bring up points of discussion before its too late
> >>
> >> But I think the most important thing is that it removes the burden of
> >> responsibility from the committer to the project as a whole, also hugely
> >> beneficial is that it makes it particularly obvious when a patch has
> reach
> >> a stalemate and forces someone to make the call.
> >>
> >> For reference on PouchDB every committer is trusted to push code, nobody
> >> (including myself) pushes their own code to master, it goes in the PR
> queue
> >> and gets a +1 from any other committer (who will usually push it), thats
> >> essentially the same process we use at mozilla and coming to think of it
> >> any other project I have worked on, any commiter has the ability to -1 a
> >> patch at which point they give a reason and usually some solution gets
> >> agreed on
> >>
> >
> > I like this system, with one small quibble about responsibility. I don't
> > think it should be seen as removing the burden of responsibility from the
> > committer to the project as a whole. It becomes easy then for everyone,
> > including the committer, to think someone else will find bugs, and no-one
> > puts in enough effort. I'd say it is still primarily the responsibility
> of
> > the committer to ensure that code is error free, but that at least one
> > person who knows that area of the code base should sign off on it. Some
> > spreading of responsibility is good, but too much can actually lead to a
> > decline in quality.
> >
> >
> > Nick
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message