bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: Development and release process
Date Mon, 18 Mar 2013 07:53:45 GMT
On 18.03.2013 06:56, Peter Koželj wrote:
> Unfortunately, for the better or for the worse, this is obviously not the
> Apache way.

Eh? There is no "Apache Way" when it comes to managing projects, other
than the premise that recoghition is gained by merit, not by decree, and
that no-one has the power to dictate how a project will be run -- such
decisions should, in general, be reached by consensus.

> But I am always opened to alternatives. Obviously there are dozens of
> Apache projects with large communities
> that seem to manage without much backing from their ticket systems just
> fine. I am curious...
> At the very minimum, we do need to move the discussions from Tickets to
> mailing lists as it's a Apache requirement,
> if I understand correctly.

You misunderstand. Neither Greg nor I ever said anything about
requirements, but we do have opinions about efficiency and
inclusiveness. Every developer is required to be subscribed to the
development list. Major decisions e.g, votes, happen on the list.
Therefore, by keeping discussions on the mailing list, rather than in a
completely disconnected issue tracking system, you'll reach more
interested parties. Moreover, it's /harder/ to keep track of comments on
the tickets than it is to keep track of discussions on the list.

There is nothing wrong with using issue trackers to track bugs, or even
tasks. I myself have used issue trackers as a project management tool --
but in different circumstances.

Let me try to give a concrete example: This community has decided to
introduce "Bloodhound enhancement proposals" as a formalized procedure
for defining and accepting feature definitions. Fine. But, why then,
once the feature has been designed and documented, take the extra step
of breaking it down into separate tasks and creating tracker entries for
those -- instead of just writing code? The exact same level of oversight
can be achieved, with much less context switching and overhead, simply
by writing informative log messages -- which are, IMO, a lot more useful
to someone who tries to understand the reasoning behind a certain piece
of code from commit history.

-- Brane

Branko Čibej
Director of Subversion | WANdisco |

View raw message