Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka, mail # dev - Maintainer system?


Copy link to this message
-
Re: Maintainer system?
Jay Kreps 2012-11-19, 18:48
Jun is just far and away the best reviewer. So maybe we should just require
that everybody get Jun to review their patches. :-)

Or, more practically, maybe Jun should put together some guidelines on what
he does and we can try to emulate.

-Jay

On Thu, Nov 8, 2012 at 2:40 PM, Prashanth Menon
<[EMAIL PROTECTED]>wrote:

> +1 from me on the maintainer system and having a primary/secondary for
> components.
>
> I also think we should try as much as possible to get at least two
> reviewers for patches that come in.  This is something I'm very guilty of
> and am trying to correct.  I get the feeling Jun is overwhelmed with patch
> reviews :)
>
> - Prashanth
>
> On Fri, Nov 2, 2012 at 12:11 PM, Neha Narkhede <[EMAIL PROTECTED]
> >wrote:
>
> > +1 on this, I like the idea of having a primary/secondary owner system
> > for each component.
> >
> > Thanks,
> > Neha
> >
> > On Thu, Nov 1, 2012 at 10:15 PM, Jun Rao <[EMAIL PROTECTED]> wrote:
> > > I think that's a good idea. It will be good to have at least 2
> > maintainers
> > > per component.
> > >
> > > I'd encourage more people to review patches. The more patches one
> > reviews,
> > > the more familiar he/she is with the components.
> > >
> > > Thanks,
> > >
> > > Jun
> > >
> > > On Thu, Oct 4, 2012 at 1:13 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
> > >
> > >> Hey guys,
> > >>
> > >> The number of developers and code base size for Kafka is getting
> larger.
> > >>
> > >> One way to help scale things gracefully would be to have an official
> > idea
> > >> of "subsystems" and have official maintainers for those. The duties
> of a
> > >> maintainer would be
> > >> 1. Be the final word on API design in that area
> > >> 2. Ensure sufficient documentation and test coverage for that
> subsystem
> > >> 3. Review all code changes in that sub-system area
> > >> 4. Ensure that patches in that area get applied in a timely fashion
> > >>
> > >> In particular I think we could do a better job of getting patches in
> in
> > a
> > >> timely manner.
> > >>
> > >> Here are what I see as logically distinct systems or areas:
> > >>
> > >>    - Producer (java and scala)
> > >>    - Consumer (java and scala)
> > >>    - Network layer (kafka.network.*)
> > >>    - Log (kafka.log.*)
> > >>    - Replication (controller, fetcher threads, hw mark stuff, etc)
> > >>    - Kafka API impl (basically just KafkaApi.scala)
> > >>    - Hadoop stuff
> > >>    - Perf tools and system tests
> > >>    - Misc other small things: metrics, utils, etc.
> > >>
> > >> Obviously many features will cut across these layers, but the idea is
> > that
> > >> by having a real owner that is responsible for that area we will get
> > higher
> > >> quality.
> > >>
> > >> I think we are doing this informally already, but making it formal
> would
> > >> help ensure you knew the right people to get input from. I think it
> > >> probably wouldn't make sense to start doing this until post-0.8 since
> we
> > >> are in the middle of so many things right now, but I wanted to see
> what
> > >> people thought...?
> > >>
> > >> -Jay
> > >>
> >
>