incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: Concerning Sentry: A disagreement over the Apache Way and graduation
Date Tue, 10 Nov 2015 20:31:43 GMT
This is an interesting topic, and one that is broader than just Apache Sentry (incubating).
Even so, I want to praise Joe Brockmeier for raising it, and the comments -especially those
from Greg Stein and Rich Bowen and Marvin Humphrey for making me think more about this.

* In any project with a pool of developers, there's going to be co-located discussions. And,
even if they don't directly affect the decision making of a project "let's get this patch
in vs that patch", they have consequences. I'll cite from historical reference, IBM's reassignment
of a lot of the Axis 1 team to other things. It wasn't a decision of the developers; there
was enough of a community to continue, but it was traumatic nonetheless.

* In any project where a significant number of the team members are expected to ship something
in approximate correlation with a release schedule imposed by product management, project
development decisions are going to follow. Similarly, priorities for weekday work by those
engineers is going to be made by other people. This not only constrains what goes in, but
providers a motivator for keeping things out if they're felt to be too risky.

* With engineers overloaded with lots of work, it's really easy to neglect patches from others
which are on't on the critical path for those releases. I'm going to point to myself here,
and my unintentional neglect of a large set of Hadoop patches that I could get in if I reviewed
them. The only time I have to do that is weekends, and there there's some expectation in my
family that parental duties get a look in.

One thing to consider in general is: is JIRA-first development conducive to developing a community?
It's great for engineering: you watch the issues you care about, discuss them all in one place,
and it deals with the challenge of scale. But it breaks a project up into a pool of JIRAs,
where each participant only watches and comments on those they care about. It removes the
ability to view the project as a whole, and breaks it up into a set of actions. Yet: how else
do we scale to the size of some of the projects at work today?

I don't have any magic answers here

* If you look at any project I work on, I'm happy to leave JIRAs open for months at a time,
until anyone picks them up. Where I'm at fault is not following up on the patches people provide,
not out of any deliberate neglect, just overcommitment.
* I do try to encourage discussion on the email lists on broader topics. on Hadoop I'all also
call out Vinod and Wittenauer for lots of work here, to try and build a community that is
more than a set of JIRAs.
* I've been known to complain (privately) when people do a JIRA-patch-commit sequence on something
which I'm known to care about, because I hate going through the morning emails to see something
was decided on while I was asleep.
* How else to encourage community?

Maybe we should embrace online conferencing more. I know it's at odds with "TZ-neutral" dev,
but with things like google hangouts we can have conversations that aren't around a single
JIRA, and can set the direction of the project across all participants. We'd just need to
make sure that people who couldn't make the call can still help set that direction, which
means standardised followons: notes -> DISCUSS -> VOTE. After all, there's been ASF
IRC channels for a long time.

-Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message