bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Dreimann <>
Subject Re: Development and release process
Date Mon, 18 Mar 2013 09:25:54 GMT

On 18 Mar 2013, at 07: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.
>> 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?

1. Tracking progress
2. Indicating if someone is already working on the issue

Since you are recognising overhead and duplication in this process, we could suggest to improve
Bloodhound along the lines of:

If bullet points in the wiki were actually checkboxes, a list of bullet points could be a
list of tasks with no extra effort. Users could just tick off the ones that are completed,
while we still have all the tracking benefits of tickets.

This has been raised as ticket #231 already. Finding this in the mailing list archives would
not have been this easy if it was sent before I subscribed (new contributor use case), never
mind that I would have also had to look for hosting of the attachment since the ML strips
those out. It obviously could not have fit into a log message or code commit (I personally
could have committed it, but it would have sat without context in the docs folder. Talk about
context switching! How could anyone have discovered that again?).

> The exact same level of oversight
> can be achieved, with much less context switching and overhead, simply
> by writing informative log messages --

(Emphasis mine) If this premise is true, then the logical conclusion must be that an issue
tracker is a waste of time. I'd argue that it is not.

Context switching is bad and should be reduced, see my previous list of suggestions for proposals
how. Good luck referring to them without ticket numbers/tags/milestone. I look forward to
your comments on how to better do this.

> which are, IMO, a lot more useful
> to someone who tries to understand the reasoning behind a certain piece
> of code from commit history.

This is where I think there's a disconnect. I have the impression that you consider that use
case in isolation and treat it like a binary choice between good log messages and value adding
issue tracking.

Let me be clear about my position from a design perspective: I believe the functionality commonly
associated with issue trackers can add value, and does in our case. The best issue tracker
than I can imagine is one that no one ever has to visit. It needs no interface and no configuration.
Yet it would be fully integrated as an ancillary service to all relevant systems and share
information between them, enriching it along the way, until those systems do so themselves.
At that point we should stop developing the issue tracker. Until that point I believe we should
strive to reduce the overhead it creates.

- Joe

> -- Brane
> -- 
> Branko Čibej
> Director of Subversion | WANdisco |

  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message