incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: Development and release process
Date Mon, 18 Mar 2013 05:56:22 GMT
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 <olemis@gmail.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message