incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Concerning Sentry: A disagreement over the Apache Way and graduation
Date Wed, 11 Nov 2015 12:27:55 GMT

> 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.
> I'm a big fan of backing all my work with issue tracker tickets, but
> *decisions* (except minor ones which only have a very local impact)
> should not happen in those tickets. IMO tickets are for execution of
> something that's been decided on your project's dev list.
> It's a difficult balance, and it requires all developers to be aware
> of when the time comes to stop discussing in a ticket and bring that
> discussion to the dev list.

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.

>> ... Maybe we should embrace online conferencing more....
> I don't think so, as that's not inclusive nor asynchronous.

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 

> IMO the combination of dev list + tickets can work well but it
> requires lots of discipline for the most active developers, to make
> sure they expose their ideas, decisions and discussions to their
> project's dev list.
> -

what we shouldn't be doing in conf calls is those big decisions, the stuff you'd vote on;
the mailing list must also be the normative history of discussions. It's just that the online
conf tooling has grown so that its fairly straightforward to have a small multuser conf with
google+ (sadly excluding all .cn participants), and an awful but global experience using Cisco


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

View raw message