incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: Development and release process
Date Sun, 17 Mar 2013 07:40:23 GMT
On 3/15/13, Olemis Lang <olemis@gmail.com> wrote:
>
[...]
>  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 .
>


I do not want to throw more wood into the fire ... but I just think
it'd be ok to spend tow minutes describing another scenario proving
the value of tickets . This happened yesterday .

Implementing #438 IMO means among other things reverting part of the
work made for #404 . In advance, as you can see , I'm already talking
in terms of tickets , which means they are useful . To the point :
even if not added in ticket comments the two first changesets
mentioned in #404 may be easily found this way (notice ticket ref ;) :

{{{
#!sh

$ hg log --template="[{svnrev}] - {desc}\n" | grep "#404"
[1449636] - #404 - Populate default schema on product addition (copy
TRAC_ADMIN from globals to newly created product)
[1448946] - #404 - Populate default schema on product addition
(initial implementation)

}}}

I went after reverting those changes but there was nothing like that
in multiproduct/util.py at bep_0003_multiproduct head , since
everything was moved onto API in r1456434 which lacks a reference to
#404 . If we were focusing on commit only without paying attention to
record traces in the issue tracker then I had to spend considerable
time looking for ┬źdangling┬╗ changesets like the third one .
Fortunately jure added a note in #404 and I could find it right away .

PS: BTW, all this is still work in progress .

-- 
Regards,

Olemis.

Mime
View raw message