incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <>
Subject Re: Concerning Sentry: A disagreement over the Apache Way and graduation
Date Wed, 11 Nov 2015 18:16:03 GMT
"Trust is the basis of a healthy community"

-- For sure.

"and RTC (via Jira or otherwise) just screams "we don't trust you. we
must review all commits first.""

-- I disagree.  RTC has merit independent of concerns of trust.  If
trust issues are present in a community then any number of challenges
will exist and all processes will suffer.  Keep in mind RTC applies to
everyone (PMC, committer, contributor).  So it isn't about trust at
all.  It is about community.

Not wanting to sidetrack this thread but also didn't want that comment
to go without a counter.


On Wed, Nov 11, 2015 at 12:59 PM, Greg Stein <> wrote:
> On Wed, Nov 11, 2015 at 6:27 AM, Steve Loughran <>
> wrote:
>> > On 11 Nov 2015, at 09:38, Bertrand Delacretaz <>
>> wrote:
>> >
>> > Hi Steve,
>> >
>> > On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran <>
>> wrote:
>> >> JIRA-first development conducive to developing a community?...
>> >
>> > I don't think so, as you say this breaks the project into very small
>> > buckets and it's very hard for someone new to get the overview of
>> > what's going on and what the big ideas and visions are.
> Agreed.
> I also find it sad that work is *gated* by using Jira first. We should be
> trusting our peers, let them commit changes necessary, and review their
> work afterwards. Trust is the basis of a healthy community, and RTC (via
> Jira or otherwise) just screams "we don't trust you. we must review all
> commits first."
>> One of the troublespots is those "minor" patches which have traumatic
>> consequences; you don't notice when the issue is created, don't watch it,
>> and then, when its merged in, you discover that things now behave
>> differently. Anything related to specific dependency updates are things to
>> watch there (guava, jackson, jersey), but it could be something more subtle
>> like a change in the concurrency model of some bit of code. It's only later
>> that you find your code has stopped working and you are left trying to work
>> out what happened and why.
> I'm not sure what the above has to do with issues/Jira. Any commit can have
> this effect, whether it was done directly or via an issue. It's just a
> typical problem with development.
> (and yeah, it leads into a whole separate conversation about testing and CI)
>> Noted, but we're going to try it in the slider dev group anyway, so we can
>> do some more detailed code review of various complex things more
>> interactively. I know it excludes people who can't be there, but its still
>> more inclusive of
> I see no problem doing code reviews this way, as other devs can still
> comment/review whatever output gets committed. They're only "shut out" of
> the first review, not ALL review.
> Using them for initial code development or decisions? Not so much.
> Using them to reach a consensus among a subset of the community? Sure, and
> bring that result to the dev@ list to reach full community consensus. We
> see this done all the time with hackathons: the group at the 'thon come up
> with some idea they all like, and bring that to the dev@ list. 10 people
> think it is the right approach and share it, then rope in the other 10.
> Cheers,
> -g

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message