bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <>
Subject Re: Development and release process
Date Fri, 15 Mar 2013 05:19:13 GMT
On Thu, Mar 14, 2013 at 7:03 AM, Peter Koželj <> wrote:

> There has been several requests from our mentors to be less ticket savvy.
> While I do not agree that our BH should be used for bug tracking
> exclusively
> (Jira and similar have served me as planning tools quite successfully in
> the past),
>  I can see some room to relax our process a bit.
> There is on thing that I would like to suggest if we are going that way:
> Every (or almost every) commit or patch should also include a modification
> to RELEASE_NOTES (ticket  based or not).
> There should be no need to preoccupy release manager with what was done,
> what the status is and so forth.
> When the release date comes, it should be trivial for release manager to
> get the release notes
> into consistent and presentable state.
> Disclaimer: I am not suggesting that we retire our issue tracker.
> Bloodhound needs to eat it's own dog food after all.

Hi Peter,

I'll try to explain my thinking on this. I'm asking myself, what is the
value of tickets and release notes for the developers and for our users?
Let me describe two experiences.

The Trac project has been around for a while now, so users are running a
wide range of versions, and a typical user is not running the latest
version. Fairly often, a user will report an issue on the mailing list or
in a ticket and that issue will have been resolved already in an existing
or upcoming release. When I find that ticket, I want to be able to
immediately see what release the issue has been resolved in, therefore I
find value in a properly-set milestone field. Sometimes I will see a new
feature or change that I may not like. Rather than possibly rehashing this
immediately on the mailing list, I've found it useful to be able to review
the ticket in which the change was made and see the considerations and
decision making that led to the change.

In contrast, I've found a RELEASE_NOTES file //with very detailed changes//
to be tedious to manage and not all that useful in imparting information
about the changes that were made. However, I really like what the Trac
project has done via a //Release Notes// field in their tickets, and
generation of a Release Notes page using wiki macros (1). I worked with the
Trac devs on many tickets for the last release, and found this process to
be low overhead. So I suppose I would be in favor of following the "Trac
process" of release notes generation, or being very relaxes in our
processes leading up to 1.0, but I don't think that managing a
RELEASE_NOTES file will be better than either of the other two options.

My contrasting experience is, that I worked the past few years on a team of
4 developers and we followed the "Trac process" to create the release
notes. This was for a medical devices, so there will never be any end users
reviewing our release notes - they were for developers and internal company
use only. Following the "Trac process" of release notes generation
fulfilled some regulatory requirements, but aside from that, I did not see
much value in it, and had this not been a regulated product, I wouldn't
have put the effort into producing detailed release notes. I mentioned
because, at the current stage in Bloodhound development, we may have more
in common with that medical device project than we have with the Trac

My conclusion is - Of course time spent managing tickets must be small, and
there should be minimal overhead for developers and release managers. What
I'm hearing from you and others points to that being the goal of everyone.
The Bloodhound project does not have many releases yet, few to zero users
and a manageable number of tickets. While establishing our process and good
practices early on can pay off down the road, we have to weigh that against
work that will be incurred, and it may not be worth making much change to
our process and being more careful, organized and detailed until we get to
release 1.0. Given that, I'd favor continuing to do what we do now, with a
small and concise RELEASE_NOTES file, but developers should update that
file when they make major changes, so that the release manager manager's
responsibility is limited to reviewing the file and making sure nothing big
has been overlooked. Once we get a user base established, I'd favor moving
to something like the "Trac process" of release notes generation.

Anyway, I apologize for the lengthy reply, but I wanted to explain why I
think a bit of organization is good at the appropriate phase of a project.
I hope we can rapidly reach a conclusion on what the community feels is
best, and I will try not to say much more on the subject.


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