I have not seen the discussion to which you refer. The issue, in my
experience, is that it really takes the project lead being extremely
proactive about the scheduling of issues. And we just don't have that
type of bandwidth.
On Fri 04 Nov 2011 05:40:15 AM CDT, Emmanuel Bernard wrote:
## Timeline and work to do
Hibernate Core goes final next week if things go as planned. So it's time for us to
gear towards a CR2 and release it right after Core goes final. I have done some JIRA
cleanup and everything I think is important is tagged as fix version 4.0.0.CR2. Please
have a look, pick up issues and fix them.
Also have a look at issues marked as 4.0.0.Final which I don't think any is critical
or realistic to put in this release. See my rant about managing JIRA below on the subject.
Once you have looked at them I will nuke their fix version field into oblivion.
4.0 will target Infinispan 5.0. A week or two from CR, we will go final.
4.1 will be a short cycle targeted for mid december (the final version). The idea is to
align with Infinispan 5.1 and add whatever useful feature or fix we think is important.
## Managing JIRA
JIRA is not exactly a list to Santa Claus. Let me rephrase, JIRA is not a list to Santa
Claus. You can't put a version number to a JIRA issue and hope things will magically
be fixed in this version. The rule of thumb is simple:
1. If you think you will do it, set the version number
2. If you know someone that will likely do it, put a version number
3. if it's vitally important that this be fixed in the next version, see rule #1
Otherwise don't put a version number without asking the project lead
The rule is a bit different for the project lead as he has to draw the big picture of
what a release will contain and assigning a number is the easiest solution. A corollary is
that moving a problem from version n to version n+1 is useless.
Today we ended up with 60 issues that ought to be resolved in less than a week. That
obviously is beyond our capacity.
Of course these rules are not hard enforced but we definitively need to shift back into a
more conservative version assignment management.
By the way, I don't know if you have followed AS 7's team rant on JIRA and
actionable items. While I'm not 100% inlined with their rule, I am sympathetic to the
idea of a managed flow of JIRA issues. I'm not sure how this can be applied to (or at
least get closer with) search, validator and ogm but I'm open to ideas.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve(a)hibernate.org
http://hibernate.org