[hibernate-dev] [HSEARCH] *.next Jira versions

[Gunnar Morling]

2015-01-27 23:41 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> Ok, all outdated versions are now either pruned or archived.
>
> I'm still keeping 4.4.next and 4.5.next around for a little longer, as
> some final touches are needed before we close these.
>

Thanks!

What's the suggestion for components?
>

I don't have any preference.

I wouldn't delete any "old" components. There is a feature request for
making JIRA issues archivable (just as versions), but that's not there yet
and they don't have immediate plans to do so. If the legacy components
really bother you, you might consider to rename them ("xxx_optimizer") so
they only show up at the end in drop-downs.


> These I'd want to keep:
>  - documentation
>  - testing
>  - build
> I guess these never were much of a source of confusion?
>
> These I don't think are a good fit any more - unless we want a very
> precise granularity:
>  - optimizer (Any Optimizer is deprecated)
>  - directory provider (Except the MasterDP, they are all trivial -
> we'd probably focus on the more general IndexManager nowadays)
>
> These I think are quite well defined, but I'm not sure if we're all on
> the same page:
>  - backend
>  - query
>  - serialization
>  - spatial
>  - mapping
>
> The "infinispan" is becoming tricky. It used to be just "those things
> in the /infinispan module", but nowadays we have many more
> interactions - not least some issues have been tagged with this with
> the (wrong IMO) meaning of "needed for Infinispan" as in blocking some
> issue in the Infinispan Query project.
>
> But remember that deleting unused components has consequences: affects
> a thousand closed issues. I'd rather accept that these will not be
> used much anymore.
> Adding new components also better be worth it, as you'd have to accept
> either of two evils:
>  A) you'll need to re-classify all existing issues
>  B) you'll have to accept that old issues won't show up classified
> nicely, in case you're searching for them or looking at per-component
> metrics over time..
>
> Sanne
>
> On 27 January 2015 at 22:08, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
> > Hi,
> >
> > On Tue, Jan 27, 2015 at 07:00:15PM +0100, Gunnar Morling wrote:
> >> There are many (new?) versions in Jira such as 3.1.next, 3.2.next etc.
> >>
> >> Are those all needed? 5.x makes sense to me, and maybe 4.5.next, but all
> >> the old ones? All these unreleased versions make it a bit unwieldy when
> >> assigning a fix version to an issue.
> >
> > +1 I also find it unwieldy, not only for assigning a fix version, but
> also when
> > "browsing" by version when on the project home page. I also find it
> sub-optimal
> > that if on the project summary the visible versions are 3.1.next,
> 3.2.next ... 4.1.next.
> >
> > This is partly related to the components discussion we had a while back.
> IMO
> > HSEARCH Jira needs a bit of a make-over.
> >
> > --Hardy
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>