Thanks for the feedback. We actually think alike. I found the ticket per task (not talking about one liners fixed along the way here) organization with tracking system generated release notes most useful myself also. I also do not perceive the tickets as a big overhead either.
Unfortunately, for the better or for the worse, this is obviously not the Apache way. 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. Peter On 17 March 2013 08:40, Olemis Lang <[email protected]> wrote: > On 3/15/13, Olemis Lang <[email protected]> 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. >
