You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Peter Koželj <pe...@digiverse.si> on 2013/03/14 15:03:30 UTC
Development and release process
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.
Peter
Re: Development and release process
Posted by Olemis Lang <ol...@gmail.com>.
On 3/15/13, Olemis Lang <ol...@gmail.com> wrote:
[...]
> (e.g. IBM Rational ClearCase et al. , ... I've even written one
> such integration for Trac in the past ;)
>
my mistake ... IBM Rational Requisite Pro .
--
Regards,
Olemis.
Re: Development and release process
Posted by Olemis Lang <ol...@gmail.com>.
On 3/18/13, Branko Čibej <br...@wandisco.com> wrote:
> On 18.03.2013 06:56, Peter Koželj wrote:
[...]
>>
>> 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.
>
[...]
>
> Let me try to give a concrete example: This community has decided to
> introduce "Bloodhound enhancement proposals" as a formalized procedure
> for defining and accepting feature definitions.
In part , yes, BEPs are mainly aimed at helping in fleshing out ideas
by consolidating a big and complicated proposal that is hard to
understand by following ML discussion threads . There's even no need
to create one such document to get features in .
> Fine. But, why then,
> once the feature has been designed and documented, take the extra step
> of breaking it down into separate tasks and creating tracker entries for
> those -- instead of just writing code?
[...]
Because :
1. the wiki page is a very bad resource to track feature comments ,
changesets traceability , regressions , test failures ...
2. not everything that's been done is documented in detail in BEPs
just the surface , the overall picture (e.g. for BEP 3
consider multiproduct UI tickets, permission policy , ...)
3. there should be a list of tickets implementing BEP in
implementation notes section
in order to not to make this happen without major efforts involved a
wiki to ticket solution may be installed in place . just one click
required .
PS: all that is IMO
--
Regards,
Olemis.
Re: Development and release process
Posted by Olemis Lang <ol...@gmail.com>.
On 3/18/13, Branko Čibej <br...@wandisco.com> wrote:
> On 18.03.2013 22:11, Olemis Lang wrote:
>> On 3/18/13, Branko Čibej <br...@wandisco.com> wrote:
[...]
>>
>> Is there some kind of support in subversion for distributed VCS
>> notifications (be it web hooks or whatever other name ...) that might
>> help us to establish those interactions with i.a.o issue tracker ?
>
> Yes, we have svnpubsub, a publish/subscribe framework for signalling
> changes in the repository. It was developed inside ASF Infra, and is now
> in the Subversion source tree and will be released with the 1.8 package.
> It's used for publishing all ASF project websites, for example.
that is good news !
> It would
> make perfect sense to teach BH to be an svnpubsub client.
>
of course ! awesome !
\o/
afaics we should be ready to put all the pieces in the right place ;
seems to be just a matter of time ...
> And of course, svnpubsub is written in Python. :)
>
I swear I did not know ... :)
--
Regards,
Olemis.
Re: Development and release process
Posted by Branko Čibej <br...@wandisco.com>.
On 18.03.2013 22:11, Olemis Lang wrote:
> On 3/18/13, Branko Čibej <br...@wandisco.com> wrote:
>> How hard, exactly, would it be to teach BH to look at remote
>> (Subversion) repositories? I know that the current SVN repository
>> connector requires that, but I haven't been able to figure out how
>> deeply ingrained in Trac is the assumption of local access.
>>
> There is an initial work [2]_ towards that goal but seems to be either
> abandoned or not supported at all . Nevertheless maybe there's a
> chance to continue from that point forward , or otherwise get this
> done from scratch .
>
> However , that would not be enough when it comes to enabling hooks in
> that configuration , as that'd require at least some kind of web hooks
> installed in place . trackhacks:TracWebHooksPlugin is aimed at making
> Trac to offer one such distributed notifications scenario . So the
> issue tracker would be the hooks provider (instead of the consumer ,
> which what we'd need ;) so that would not be useful to get Joachim
> suggestion done .
>
> Is there some kind of support in subversion for distributed VCS
> notifications (be it web hooks or whatever other name ...) that might
> help us to establish those interactions with i.a.o issue tracker ?
Yes, we have svnpubsub, a publish/subscribe framework for signalling
changes in the repository. It was developed inside ASF Infra, and is now
in the Subversion source tree and will be released with the 1.8 package.
It's used for publishing all ASF project websites, for example. It would
make perfect sense to teach BH to be an svnpubsub client.
And of course, svnpubsub is written in Python. :)
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Development and release process
Posted by Olemis Lang <ol...@gmail.com>.
On 3/18/13, Branko Čibej <br...@wandisco.com> wrote:
> On 18.03.2013 12:30, Joachim Dreimann wrote:
>>
[...]
>> Ok, so my suggestion would be that whenever a commit message mentions a
>> ticket, it gets added to the ticket as a comment.
>> - Poor commit messages get more exposure that way
>> - It encourages people to refer to tickets providing more context ( NOT a
>> substitute for a good commit message)
>> - Developers don't need to also add a comment to Bloodhound directly, the
>> commit message will do.
>
> This sounds like something BH should automate, post 1.0 :) I bet there
> are already Trac plugins for that.
>
If I understood correctly , we could be doing this right away [1]_ ,
but we'll need VCS (svn, git, ...) hooks to make it happen . To work
towards an enhanced user experience for BH>1.0 it'd be an option to
suggest trachacks:RepositoryHookSystemPlugin which is aimed at
providing a VCS-agnostic solution to manage hooks . Many enhancements
needed , included better integration with Windows OS . FWIW I'm the
maintainer .
>> For that Bloodhound would need some awareness of the repository; that has
>> never been available since we started the project, and has been an open
>> Jira ticket since last July(!):
>> https://issues.apache.org/jira/browse/INFRA-5064
>>
>> Greg and Brane, how do you suggest we can get progress on this? We've
>> followed up on this quite a few times: via IRC, email and in board
>> reports.
>> Gary has also just raised the priority.
>
> How hard, exactly, would it be to teach BH to look at remote
> (Subversion) repositories? I know that the current SVN repository
> connector requires that, but I haven't been able to figure out how
> deeply ingrained in Trac is the assumption of local access.
>
There is an initial work [2]_ towards that goal but seems to be either
abandoned or not supported at all . Nevertheless maybe there's a
chance to continue from that point forward , or otherwise get this
done from scratch .
However , that would not be enough when it comes to enabling hooks in
that configuration , as that'd require at least some kind of web hooks
installed in place . trackhacks:TracWebHooksPlugin is aimed at making
Trac to offer one such distributed notifications scenario . So the
issue tracker would be the hooks provider (instead of the consumer ,
which what we'd need ;) so that would not be useful to get Joachim
suggestion done .
Is there some kind of support in subversion for distributed VCS
notifications (be it web hooks or whatever other name ...) that might
help us to establish those interactions with i.a.o issue tracker ?
PS: BTW I also found trac:#2523 [3]_ which might be related to the
workflow suggested by Greg in previous messages .
.. [1] Commit Ticket Updater
(http://trac.edgewall.org/wiki/CommitTicketUpdater)
.. [2] Remote SVN plugin
(http://www.meadowy.org/~gotoh/hg/remote-svn-plugin/)
.. [3] #2523 (TODO's from Sourcecode as a ticket) – The Trac Project
(http://trac.edgewall.org/ticket/2523)
--
Regards,
Olemis.
Re: Development and release process
Posted by Branko Čibej <br...@wandisco.com>.
On 18.03.2013 12:30, Joachim Dreimann wrote:
> On 18 March 2013 10:14, Gary Martin <ga...@wandisco.com> wrote:
>
>> On 18/03/13 09:26, Peter Koželj wrote:
>>
>>> On 18 March 2013 08:53, Branko Čibej <br...@wandisco.com> wrote:
>>>
>>> On 18.03.2013 06:56, Peter Koželj wrote:
>>>>> [...]
>>>> There is nothing wrong with using issue trackers to track bugs, or even
>>>> tasks. I myself have used issue trackers as a project management tool --
>>>> but in different circumstances.
>>>>
>>>> Let me try to give a concrete example: This community has decided to
>>>> introduce "Bloodhound enhancement proposals" as a formalized procedure
>>>> for defining and accepting feature definitions. Fine. But, why then,
>>>> once the feature has been designed and documented, take the extra step
>>>> of breaking it down into separate tasks and creating tracker entries for
>>>> those -- instead of just writing code? The exact same level of oversight
>>>> can be achieved, with much less context switching and overhead, simply
>>>> by writing informative log messages -- which are, IMO, a lot more useful
>>>> to someone who tries to understand the reasoning behind a certain piece
>>>> of code from commit history.
>>>>
>> I can't deny that last bit of logic as it is a bit self referential. Yes,
>> we want to see good log messages to enable scrutiny through the log.
>> However, we should also benefit through linking commits to a ticket which
>> is an easier way to put a change in context. A commit message is often
>> going to be more about what happened than why.
>>
> Ok, so my suggestion would be that whenever a commit message mentions a
> ticket, it gets added to the ticket as a comment.
> - Poor commit messages get more exposure that way
> - It encourages people to refer to tickets providing more context ( NOT a
> substitute for a good commit message)
> - Developers don't need to also add a comment to Bloodhound directly, the
> commit message will do.
This sounds like something BH should automate, post 1.0 :) I bet there
are already Trac plugins for that.
> For that Bloodhound would need some awareness of the repository; that has
> never been available since we started the project, and has been an open
> Jira ticket since last July(!):
> https://issues.apache.org/jira/browse/INFRA-5064
>
> Greg and Brane, how do you suggest we can get progress on this? We've
> followed up on this quite a few times: via IRC, email and in board reports.
> Gary has also just raised the priority.
How hard, exactly, would it be to teach BH to look at remote
(Subversion) repositories? I know that the current SVN repository
connector requires that, but I haven't been able to figure out how
deeply ingrained in Trac is the assumption of local access.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Development and release process
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 18 March 2013 10:14, Gary Martin <ga...@wandisco.com> wrote:
> On 18/03/13 09:26, Peter Koželj wrote:
>
>> On 18 March 2013 08:53, Branko Čibej <br...@wandisco.com> wrote:
>>
>> On 18.03.2013 06:56, Peter Koželj wrote:
>>>
>>>> [...]
>>>
>>> There is nothing wrong with using issue trackers to track bugs, or even
>>> tasks. I myself have used issue trackers as a project management tool --
>>> but in different circumstances.
>>>
>>> Let me try to give a concrete example: This community has decided to
>>> introduce "Bloodhound enhancement proposals" as a formalized procedure
>>> for defining and accepting feature definitions. Fine. But, why then,
>>> once the feature has been designed and documented, take the extra step
>>> of breaking it down into separate tasks and creating tracker entries for
>>> those -- instead of just writing code? The exact same level of oversight
>>> can be achieved, with much less context switching and overhead, simply
>>> by writing informative log messages -- which are, IMO, a lot more useful
>>> to someone who tries to understand the reasoning behind a certain piece
>>> of code from commit history.
>>>
>>
> I can't deny that last bit of logic as it is a bit self referential. Yes,
> we want to see good log messages to enable scrutiny through the log.
> However, we should also benefit through linking commits to a ticket which
> is an easier way to put a change in context. A commit message is often
> going to be more about what happened than why.
>
Ok, so my suggestion would be that whenever a commit message mentions a
ticket, it gets added to the ticket as a comment.
- Poor commit messages get more exposure that way
- It encourages people to refer to tickets providing more context ( NOT a
substitute for a good commit message)
- Developers don't need to also add a comment to Bloodhound directly, the
commit message will do.
For that Bloodhound would need some awareness of the repository; that has
never been available since we started the project, and has been an open
Jira ticket since last July(!):
https://issues.apache.org/jira/browse/INFRA-5064
Greg and Brane, how do you suggest we can get progress on this? We've
followed up on this quite a few times: via IRC, email and in board reports.
Gary has also just raised the priority.
--
Joe Dreimann
UX Designer | WANdisco <http://www.wandisco.com/>
Re: Development and release process
Posted by Gary Martin <ga...@wandisco.com>.
On 18/03/13 09:26, Peter Koželj wrote:
> On 18 March 2013 08:53, Branko Čibej <br...@wandisco.com> wrote:
>
>> On 18.03.2013 06:56, Peter Koželj wrote:
>>> Unfortunately, for the better or for the worse, this is obviously not the
>>> Apache way.
>> Eh? There is no "Apache Way" when it comes to managing projects, other
>> than the premise that recoghition is gained by merit, not by decree, and
>> that no-one has the power to dictate how a project will be run -- such
>> decisions should, in general, be reached by consensus.
>>
> Ok, good to hear that.
>
>
>>> 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.
>> You misunderstand. Neither Greg nor I ever said anything about
>> requirements, but we do have opinions about efficiency and
>> inclusiveness. Every developer is required to be subscribed to the
>> development list. Major decisions e.g, votes, happen on the list.
>> Therefore, by keeping discussions on the mailing list, rather than in a
>> completely disconnected issue tracking system, you'll reach more
>> interested parties. Moreover, it's /harder/ to keep track of comments on
>> the tickets than it is to keep track of discussions on the list.
>>
> That "harder" is a bit subjective. For someone who is interested in
> everything that has to do with project, I agree.
> For someone who is only interested in only a feature or two it is probably
> easier.
There is definitely a tradeoff here between the noise of lots of issues
being discussed and the ability to focus on specific issues. However, we
may have problems with the discoverability of these discussions if we
were to stick only to tickets. Moving discussions from the issue tracker
to the mailing list should benefit overall inclusiveness on the
assumption that everyone is on the mailing list and that interested
parties are more likely to be looking there.
> Personally I think the problem I am seeing is that we kind of choose to
> discuss every little detail to death instead of
> just doing it. The mechanics we choose (tickets vs. ML) is of much lesser
> concern to me.
Yes, this is something that seems to crop up a fair bit. I would hope
that discussion being on the dev list would make it quicker for people
to call out such behaviour.
>> There is nothing wrong with using issue trackers to track bugs, or even
>> tasks. I myself have used issue trackers as a project management tool --
>> but in different circumstances.
>>
>> Let me try to give a concrete example: This community has decided to
>> introduce "Bloodhound enhancement proposals" as a formalized procedure
>> for defining and accepting feature definitions. Fine. But, why then,
>> once the feature has been designed and documented, take the extra step
>> of breaking it down into separate tasks and creating tracker entries for
>> those -- instead of just writing code? The exact same level of oversight
>> can be achieved, with much less context switching and overhead, simply
>> by writing informative log messages -- which are, IMO, a lot more useful
>> to someone who tries to understand the reasoning behind a certain piece
>> of code from commit history.
I can't deny that last bit of logic as it is a bit self referential.
Yes, we want to see good log messages to enable scrutiny through the
log. However, we should also benefit through linking commits to a ticket
which is an easier way to put a change in context. A commit message is
often going to be more about what happened than why.
Cheers,
Gary
Re: Development and release process
Posted by Peter Koželj <pe...@digiverse.si>.
On 18 March 2013 08:53, Branko Čibej <br...@wandisco.com> wrote:
> On 18.03.2013 06:56, Peter Koželj wrote:
> > Unfortunately, for the better or for the worse, this is obviously not the
> > Apache way.
>
> Eh? There is no "Apache Way" when it comes to managing projects, other
> than the premise that recoghition is gained by merit, not by decree, and
> that no-one has the power to dictate how a project will be run -- such
> decisions should, in general, be reached by consensus.
>
Ok, good to hear that.
>
> > 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.
>
> You misunderstand. Neither Greg nor I ever said anything about
> requirements, but we do have opinions about efficiency and
> inclusiveness. Every developer is required to be subscribed to the
> development list. Major decisions e.g, votes, happen on the list.
> Therefore, by keeping discussions on the mailing list, rather than in a
> completely disconnected issue tracking system, you'll reach more
> interested parties. Moreover, it's /harder/ to keep track of comments on
> the tickets than it is to keep track of discussions on the list.
>
That "harder" is a bit subjective. For someone who is interested in
everything that has to do with project, I agree.
For someone who is only interested in only a feature or two it is probably
easier.
Personally I think the problem I am seeing is that we kind of choose to
discuss every little detail to death instead of
just doing it. The mechanics we choose (tickets vs. ML) is of much lesser
concern to me.
>
> There is nothing wrong with using issue trackers to track bugs, or even
> tasks. I myself have used issue trackers as a project management tool --
> but in different circumstances.
>
> Let me try to give a concrete example: This community has decided to
> introduce "Bloodhound enhancement proposals" as a formalized procedure
> for defining and accepting feature definitions. Fine. But, why then,
> once the feature has been designed and documented, take the extra step
> of breaking it down into separate tasks and creating tracker entries for
> those -- instead of just writing code? The exact same level of oversight
> can be achieved, with much less context switching and overhead, simply
> by writing informative log messages -- which are, IMO, a lot more useful
> to someone who tries to understand the reasoning behind a certain piece
> of code from commit history.
>
> -- Brane
>
>
> --
> Branko Čibej
> Director of Subversion | WANdisco | www.wandisco.com
>
>
Re: Development and release process
Posted by Joe Dreimann <jo...@wandisco.com>.
On 18 Mar 2013, at 07:53, Branko Čibej <br...@wandisco.com> wrote:
> On 18.03.2013 06:56, Peter Koželj wrote:
>> Unfortunately, for the better or for the worse, this is obviously not the
>> Apache way.
>
> Eh? There is no "Apache Way" when it comes to managing projects, other
> than the premise that recoghition is gained by merit, not by decree, and
> that no-one has the power to dictate how a project will be run -- such
> decisions should, in general, be reached by consensus.
>
>> 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.
>
> You misunderstand. Neither Greg nor I ever said anything about
> requirements, but we do have opinions about efficiency and
> inclusiveness. Every developer is required to be subscribed to the
> development list. Major decisions e.g, votes, happen on the list.
> Therefore, by keeping discussions on the mailing list, rather than in a
> completely disconnected issue tracking system, you'll reach more
> interested parties. Moreover, it's /harder/ to keep track of comments on
> the tickets than it is to keep track of discussions on the list.
>
> There is nothing wrong with using issue trackers to track bugs, or even
> tasks. I myself have used issue trackers as a project management tool --
> but in different circumstances.
>
> Let me try to give a concrete example: This community has decided to
> introduce "Bloodhound enhancement proposals" as a formalized procedure
> for defining and accepting feature definitions. Fine. But, why then,
> once the feature has been designed and documented, take the extra step
> of breaking it down into separate tasks and creating tracker entries for
> those -- instead of just writing code?
1. Tracking progress
2. Indicating if someone is already working on the issue
Since you are recognising overhead and duplication in this process, we could suggest to improve Bloodhound along the lines of:
If bullet points in the wiki were actually checkboxes, a list of bullet points could be a list of tasks with no extra effort. Users could just tick off the ones that are completed, while we still have all the tracking benefits of tickets.
This has been raised as ticket #231 already. Finding this in the mailing list archives would not have been this easy if it was sent before I subscribed (new contributor use case), never mind that I would have also had to look for hosting of the attachment since the ML strips those out. It obviously could not have fit into a log message or code commit (I personally could have committed it, but it would have sat without context in the docs folder. Talk about context switching! How could anyone have discovered that again?).
https://issues.apache.org/bloodhound/ticket/231
> The exact same level of oversight
> can be achieved, with much less context switching and overhead, simply
> by writing informative log messages --
(Emphasis mine) If this premise is true, then the logical conclusion must be that an issue tracker is a waste of time. I'd argue that it is not.
Context switching is bad and should be reduced, see my previous list of suggestions for proposals how. Good luck referring to them without ticket numbers/tags/milestone. I look forward to your comments on how to better do this.
> which are, IMO, a lot more useful
> to someone who tries to understand the reasoning behind a certain piece
> of code from commit history.
This is where I think there's a disconnect. I have the impression that you consider that use case in isolation and treat it like a binary choice between good log messages and value adding issue tracking.
Let me be clear about my position from a design perspective: I believe the functionality commonly associated with issue trackers can add value, and does in our case. The best issue tracker than I can imagine is one that no one ever has to visit. It needs no interface and no configuration. Yet it would be fully integrated as an ancillary service to all relevant systems and share information between them, enriching it along the way, until those systems do so themselves. At that point we should stop developing the issue tracker. Until that point I believe we should strive to reduce the overhead it creates.
- Joe
>
> -- Brane
>
>
> --
> Branko Čibej
> Director of Subversion | WANdisco | www.wandisco.com
>
Re: Development and release process
Posted by Branko Čibej <br...@wandisco.com>.
On 18.03.2013 06:56, Peter Koželj wrote:
> Unfortunately, for the better or for the worse, this is obviously not the
> Apache way.
Eh? There is no "Apache Way" when it comes to managing projects, other
than the premise that recoghition is gained by merit, not by decree, and
that no-one has the power to dictate how a project will be run -- such
decisions should, in general, be reached by consensus.
> 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.
You misunderstand. Neither Greg nor I ever said anything about
requirements, but we do have opinions about efficiency and
inclusiveness. Every developer is required to be subscribed to the
development list. Major decisions e.g, votes, happen on the list.
Therefore, by keeping discussions on the mailing list, rather than in a
completely disconnected issue tracking system, you'll reach more
interested parties. Moreover, it's /harder/ to keep track of comments on
the tickets than it is to keep track of discussions on the list.
There is nothing wrong with using issue trackers to track bugs, or even
tasks. I myself have used issue trackers as a project management tool --
but in different circumstances.
Let me try to give a concrete example: This community has decided to
introduce "Bloodhound enhancement proposals" as a formalized procedure
for defining and accepting feature definitions. Fine. But, why then,
once the feature has been designed and documented, take the extra step
of breaking it down into separate tasks and creating tracker entries for
those -- instead of just writing code? The exact same level of oversight
can be achieved, with much less context switching and overhead, simply
by writing informative log messages -- which are, IMO, a lot more useful
to someone who tries to understand the reasoning behind a certain piece
of code from commit history.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Development and release process
Posted by Peter Koželj <pe...@digiverse.si>.
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 <ol...@gmail.com> wrote:
> On 3/15/13, Olemis Lang <ol...@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.
>
Re: Development and release process
Posted by Olemis Lang <ol...@gmail.com>.
On 3/15/13, Olemis Lang <ol...@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.
Re: Development and release process
Posted by Olemis Lang <ol...@gmail.com>.
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 <ry...@wandisco.com> wrote:
> On Thu, Mar 14, 2013 at 7:03 AM, Peter Koželj <pe...@digiverse.si> 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,
+
[...]
--
Regards,
Olemis.
Re: Development and release process
Posted by Ryan Ollos <ry...@wandisco.com>.
On Thu, Mar 14, 2013 at 7:03 AM, Peter Koželj <pe...@digiverse.si> 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
project.
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.
(1) http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/1.0