incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Development and release process
Date Fri, 15 Mar 2013 07:22:00 GMT
Hi !

I've been silently skipping this kind of threads to stay out of the
way , mainly because there is a big true behind the fact that some
discussions we've had in the past were unnecessarily long ... even if
in the long run they have served to the purpose of very-late agreement
( <ot> like in that historic moment when brane for the first time
*completely agreed* with me ;) ... after some time /me insisting so
hard ... </ot> )

... Ryan pulled the trigger ... :P

On 3/15/13, Ryan Ollos <> wrote:
> 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.

I see your point ... but from the outside and based on my experience ,
that would complicate things ; starting with the fact that developers
will be more concentrated in writing the release notes rather than
code . That is substantially different to having a custom field edited
from time to time when is really necessary (e.g. once when ticket is
closed) and then automatically put all such values side-by-side at
release time , briefly annotated with ticket metadata thus backed up
by ticket history reflecting related commits .

>> When the release date comes, it should be trivial for release manager to
>> get the release notes
>> into consistent and presentable state.
> 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.

IMHO tickets (i.e. tasks + enhancements) are the concrete bridge
between requirements and implementation thus acting as the minimal
unit of traceability in agile software . Minimal means that e.g. it's
possible to adopt heavyweight traceability and software engineering
tools (e.g. IBM Rational ClearCase et al. , ... I've even written one
such integration for Trac in the past ;) across the development
process .

As a side-note I mention that in the software projects I lead the
following policies are *extremely* mandatory :

  - Every task has to be related to a ticket
    (1 ticket may enclose different tasks)
  - Every commit has to be bound to at least
    (and preferably) one ticket
    * with Trac this happens ootb without any effort ...
    * ... though it seems BH won't enjoy such pleasure in a
      while because
      a. our repository browser is in the void atm , after several months
      b. even after it will be working it seems it will be hard to hook into
          ASF repos
      c. ... though maybe there's a chance to make such things
          happen or even extend svn to match our expectations
  - continuous code review ... which afaict is by far much more than
    using the ML for such purposes
  - ... a few more ... long story short .

In the ML there a few notable instances showing that the policy
initially installed by Gary of doing something **similar** and **keep
tickets focused** has been notoriously helpful . I'll add a few
concrete situations that have happened in the past in this very same
project :

  - @ryan : I could determine that #457 was related to #270
    in a few minutes ... guess how : traceability
  - often a features is only developed up to the point it works
    but no further ... where does the rest go : (sub) tickets
    * ... which are much better than private sticky notes
    * ... and encourage communication across the development
      team , and serve as a backlog for e.g. users troubleshooting
      the software , new developers making their way
      into the project
    * ... otherwise we'd have to remember pending tasks like
      those we've created long time ago and much later turn out
      to be useful (e.g. #162)
  - Content generation
    * which includes the RELEASE_NOTES
    * ... but could support other scenarios e.g. PPMC reports
    * I even recall that once I translated a considerable
      number of RUP doc templates into wiki pages and
      generated a big percent of it . BTW the target
      organization was required to deliver all those
      bureaucratic artifacts every quarter or so .

... but finally I'd argue that this is neither either my team nor any
other (enterprise | company | ... ) I've worked for in the past , and
thereby we should stick *as much as possible* to the ASF policies and
defined processes installed throughout many years , and improved along
the time . We'll have to hear carefully the advices provided by
persons with long experience because

  1. such practices are there for a very good reason
  2. we should not be swimming against the stream
  3. we should encourage people to spend their time wisely

Quick inline comments to express my opinion :


> therefore I
> find value in a properly-set milestone field.

what's the dashboard view for ?

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


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

... I confess I've worked before in the following areas : video games
(3D) , hardware design and manufacturing , hard real time control
systems , hosting providers , broadcasting , research , antivirus
(security ?) , social networking , finance , power generation and
distribution , mining , sports , telecom , astro and geo physics (<=
i.e. diversity)

> I did not see
> much value in it,

... and under other circumstances, outside the ASF , I'd agree ...

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





View raw message