bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <>
Subject Re: Development and release process
Date Mon, 18 Mar 2013 09:26:39 GMT
On 18 March 2013 08:53, Branko Čibej <> wrote:

> 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.

Ok, good to hear that.

> > 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.

That "harder" is a bit subjective. For someone who is interested in
everything that has to do with project, I agree.
For someone who is only interested in only a feature or two it is probably

Personally I think the problem I am seeing is that we kind of choose to
discuss every little detail to death instead of
just doing it. The mechanics we choose (tickets vs. ML) is of much lesser
concern to me.

> 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 |

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