[hibernate-dev] HSEARCH Preparations for 4.0.0 Final

Steve Ebersole steve at hibernate.org
Mon Nov 7 10:54:18 EST 2011

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

steve at hibernate.org

More information about the hibernate-dev mailing list