incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: Development and release process
Date Mon, 18 Mar 2013 10:14:15 GMT
On 18/03/13 09:26, Peter Koželj wrote:
> On 18 March 2013 08:53, Branko Čibej <brane@wandisco.com> 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
> easier.

There is definitely a tradeoff here between the noise of lots of issues 
being discussed and the ability to focus on specific issues. However, we 
may have problems with the discoverability of these discussions if we 
were to stick only to tickets. Moving discussions from the issue tracker 
to the mailing list should benefit overall inclusiveness on the 
assumption that everyone is on the mailing list and that interested 
parties are more likely to be looking there.

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

Yes, this is something that seems to crop up a fair bit. I would hope 
that discussion being on the dev list would make it quicker for people 
to call out such behaviour.

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

I can't deny that last bit of logic as it is a bit self referential. 
Yes, we want to see good log messages to enable scrutiny through the 
log. However, we should also benefit through linking commits to a ticket 
which is an easier way to put a change in context. A commit message is 
often going to be more about what happened than why.

Cheers,
     Gary


Mime
View raw message