5:40 a.m.
## 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.
9:54 a.m.
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
4:18 a.m.
New subject: [HSEARCH] JIRA guidelines
I am seeing a lot of issues being assigned to 4.1. I find it unrealistic. Below is a
gentle reminder on how I'd like us to assign versions.
On 4 nov. 2011, at 11:40, Emmanuel Bernard wrote:
## 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.
6:04 a.m.
New subject: [HSEARCH] JIRA guidelines
Sorry that's likely me moving out issues from 4.0, for what I can
certainly judge we won't be adding in 4.0 anymore, but at the same
time don't feel certain enough to remove them from schedule so I just
moved them to the next one:
for most of these 4.1 is a better guess than the current 4.0 so I hope
it's an improvement ;)
Most are still rather important or have proof of concepts / some
design done already, or are just trivial changes but not safe enough
to apply to current 4.0 CRs, so I believe in most cases it's the
correct target; for those you don't agree with please point them out
or drop them
I agree some of the *already existing* issues from 4.1 should be moves
out, like:
- HSEARCH-269 Spell check functionality needed (depends on John)
- HSEARCH-376 Delegate search to remote nodes and aggregate (far too
complex to do in short time)
- HSEARCH-794 Make FilterCachingStrategy a SPI (maybe?)
- HSEARCH-633 Allow definition of annotations at package-level in
package-info.java (not urgent/important?)
- HSEARCH-868 Support DISTINCT select on single field projection (not
urgent/important?)
and possibly more?
Sanne
6:45 a.m.
New subject: [HSEARCH] JIRA guidelines
In this light - http://community.jboss.org/wiki/PlansForHibernateSearch4x/
this is an attempt to create a page on what we should/want to focus on for the next
release.
Not sure what x stands for tbh. Once upon a time I thought we will be releasing 4.0 Final,
tightly
followed by a 4.1 mainly with bug fixes and missing optimization.
This would then be followed by an 4.2 or even 5(?) with some of the bigger changes
mentioned on
the wiki page.
However, schedules seem to have drifted. Obviously Hibernate Core + Search, but also AS,
etc.
My question really is, will 4.1 include the bigger DocumentBuilder refactorings or not?
--Hardy
On Dec 5, 2011, at 1:04 PM, Sanne Grinovero wrote:
Sorry that's likely me moving out issues from 4.0, for what I
can
certainly judge we won't be adding in 4.0 anymore, but at the same
time don't feel certain enough to remove them from schedule so I just
moved them to the next one:
for most of these 4.1 is a better guess than the current 4.0 so I hope
it's an improvement ;)
Most are still rather important or have proof of concepts / some
design done already, or are just trivial changes but not safe enough
to apply to current 4.0 CRs, so I believe in most cases it's the
correct target; for those you don't agree with please point them out
or drop them
I agree some of the *already existing* issues from 4.1 should be moves
out, like:
- HSEARCH-269 Spell check functionality needed (depends on John)
- HSEARCH-376 Delegate search to remote nodes and aggregate (far too
complex to do in short time)
- HSEARCH-794 Make FilterCachingStrategy a SPI (maybe?)
- HSEARCH-633 Allow definition of annotations at package-level in
package-info.java (not urgent/important?)
- HSEARCH-868 Support DISTINCT select on single field projection (not
urgent/important?)
and possibly more?
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:08 a.m.
New subject: [HSEARCH] JIRA guidelines
That was not working well for 4.1 which peaked at 64 unresolved issues. I have decided to
unassign all issues for version 4.1 and readded the truly important ones. We are back at 4
which is much more reasonable.
Let's make sure we don't have to hit the big reset button in the future which
should not happen if we follow the rules above.
On 5 déc. 2011, at 11:18, Emmanuel Bernard wrote:
I am seeing a lot of issues being assigned to 4.1. I find it
unrealistic. Below is a gentle reminder on how I'd like us to assign versions.
On 4 nov. 2011, at 11:40, Emmanuel Bernard wrote:
> ## 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
5219
days inactive
5268
days old
5 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Hardy Ferentschik -
Sanne Grinovero -
Steve Ebersole