incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <steve.lough...@gmail.com>
Subject Re: Flume Graduation (was Re: June reports in two weeks)
Date Sun, 27 May 2012 14:09:30 GMT
On 27 May 2012 10:40, Jukka Zitting <jukka.zitting@gmail.com> wrote:

> Hi,
>
> On Sun, May 27, 2012 at 6:29 AM, Arvind Prabhakar <arvind@apache.org>
> wrote:
> >
> >
> > I don't think this is a problem because while most Cloudera committers
> have
> > the luxury of working on the project during regular working hours, others
> > do that during their off hours. Hence the majority of contributions
> coming
> > from Cloudera.
>
> OK, fair enough.
>
> Such a scenario exists or has existed also in other Apache projects
> like Jackrabbit that I'm most familiar with. It can be a tricky
> balance to maintain a level playing field in such cases, for example
> by making sure that all relevant project discussions happen out in the
> open and that some committers don't feel like "junior partners" with
> less ability to influence the project.
>
>
Same for tomcat, Maven, etc. The presence of FTEs may increase code
quantity and quality, but it does make things a bit more exclusionary for
the part time developer who have a primary day job and some spare time
fixes/features & projects to work on.

Is that a bad thing? I don't know. I'm typing this in Firefox on Ubuntu
Linux -a lot of volunteers and FTEs have made this laptop usable. I cherish
that, and don't care that much about the dynamics of the various projects I
depend on: kernel, gnome. firefox, glipper, ... they work and are free.


> It sounds like you have a reasonably good handle on that, so I'm not
> too worried, but my instinct suggests that the strict RTC model and
> distinction between committers and (P)PMC members may be structural
> factors that could easily end up tripping that balance. Are these
> really essential tools for the project or could you live without them?
> Other solutions to the RTC model include separate maintenance branches
> with stricter review and testing requirements, and the only cases
> where I really see a need for the committer/(P)PMC separation is with
> umbrella projects or special cases like GSoC students or co-operation
> across project boundaries.
>
>
+1. RTC stops me doing little things in Hadoop like fixing typos in
comments and variable names, puts so much inertia in the patches I wrote
when I was only working on it in my copious free time, that I have had to
create a spreadsheet to track the status, and continually try to resync
those patches with the current codebase, resubmit, etc, etc. I see the
rationale, but think it makes a project significantly less agile, as well
as acting as a barrier to part time devs.

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