Re: [hibernate-dev] [HSEARCH][V6-POC] Bug tracking for the Search 6 POC

[Yoann Rodiere]

Hello,

I created the JIRA tickets regarding all the little TODOs in the Search 6
POC. Sorry about the noise, but it had to be done :)

I also created two new versions for the HSEARCH project on JIRA:

   - 6-before-POC-merge for tickets that should be addressed before merging
   the POC into the main Hibernate Search repository
   - 6-after-POC-merge for tickets that should be addressed after that merge

I also moved the tickets from 5.x to 6 because they required API changes,
and from 6 to 6-before-POC-merge because we actually already started the
work on those tickets.

To sum up:

   - Tickets we want to address before we merge the POC into the main
   Hibernate Search repository are there:
   
https://hibernate.atlassian.net/projects/HSEARCH/versions/31657/tab/release-report-todo
   - Tickets we want to address after the merge are there:
   
https://hibernate.atlassian.net/projects/HSEARCH/versions/31658/tab/release-report-todo
   - Tickets that we would like to address in 6.0, but haven't been
   scheduled yet are there:
   
https://hibernate.atlassian.net/projects/HSEARCH/versions/19151/tab/release-report-todo
   - Tickets we definitely don't want to address in 6.0, but might address
   in 6.x:
   
https://hibernate.atlassian.net/projects/HSEARCH/versions/28500/tab/release-report-todo
   - Big architectural topics requiring more discussion are still in the
   Google doc:
   
https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.c855wnz3s57i



On Fri, 6 Apr 2018 at 12:23 Yoann Rodiere  wrote:

> Thanks, we will do that.
> I may add some markers to the tickets though (component, label, ...): I
> just thought we will need to list tickets that must be solved before we
> merge the POC into the main repository.
>
> On Thu, 5 Apr 2018 at 16:12 Sanne Grinovero  wrote:
>
>> +1 to create issues in "main" project JIRA
>>
>> Since JIRA is an issue tracker, some people frown upon its usage as
>> planning tool. I also don't think it fits too well, especially when we
>> go too much in detail with upfront planning, but it's not too bad.
>> Preferrable to yet-another-tool.
>>
>> I don't think we need to "tag" them as POC-6, it's all the same project.
>>
>> Thanks,
>> Sanne
>>
>>
>>
>>
>> On 5 April 2018 at 08:07, Yoann Rodiere  wrote:
>> > Hello,
>> >
>> > With the Search 6 POC getting closer and closer to something we can
>> merge,
>> > and thus more and more complex, we are starting to see quite a lot of
>> TODOs
>> > piling up.
>> > I've been tracking most of them in a Google Doc
>> > <
>> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1
>> >
>> > so far, and it's fine for big architectural topics, but for small things
>> > it's clearly inadequate.
>> >
>> > What would you all think if we started to use the main Hibernate Search
>> > project to track the small TODOs we have in the Search 6 POC? We would
>> > probably have to add some JIRA Components that only make sense in
>> Search 6
>> > ("indexing", ...), but beyond that I don't think this would cause much
>> > trouble.
>> > The tickets would all be Tasks targeting version 6, and we could tag
>> them
>> > with a new "POC-6.0" component if you think it's necessary. Examples of
>> > tasks would be:
>> >
>> >- Native sorts in the Lucene Sort DSL extension
>> ><
>> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.1p57dh8ae6d5
>> >
>> >- Native predicates in the Lucene Predicate DSL extension
>> ><
>> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.1p57dh8ae6d5
>> >
>> >- Rework the Lucene DSL implementations to fail fast when parameter
>> >conversion errors occur
>> ><
>> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.xrk3mjaa7k9p
>> >
>> >- Polish and test Stream indexing (add CompletableFuture returns in
>> >particular)
>> >- Decide wether to use absolute or relative object path in "nested"
>> >search predicates
>> >
>> > If this feels like too much garbage for the main bug tracker, we can
>> create
>> > a separate JIRA project instead. But then this will add to the trouble
>> > we'll have to go through when merging (commits referring to tickets from
>> > another project).
>> >
>> > Sanne, all, WDYT?
>> > --
>> > Yoann Rodiere
>> > yo...@hibernate.org / yrodi...@redhat.com
>> > Software Engineer
>> > Hibernate NoORM team
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> --
> Yoann Rodiere
> yo...@hibernate.org / yrodi...@redhat.com
> Software Engineer
> Hibernate NoORM team
>
-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team

Re: [hibernate-dev] [HSEARCH][V6-POC] Bug tracking for the Search 6 POC

[Yoann Rodiere]

Thanks, we will do that.
I may add some markers to the tickets though (component, label, ...): I
just thought we will need to list tickets that must be solved before we
merge the POC into the main repository.

On Thu, 5 Apr 2018 at 16:12 Sanne Grinovero  wrote:

> +1 to create issues in "main" project JIRA
>
> Since JIRA is an issue tracker, some people frown upon its usage as
> planning tool. I also don't think it fits too well, especially when we
> go too much in detail with upfront planning, but it's not too bad.
> Preferrable to yet-another-tool.
>
> I don't think we need to "tag" them as POC-6, it's all the same project.
>
> Thanks,
> Sanne
>
>
>
>
> On 5 April 2018 at 08:07, Yoann Rodiere  wrote:
> > Hello,
> >
> > With the Search 6 POC getting closer and closer to something we can
> merge,
> > and thus more and more complex, we are starting to see quite a lot of
> TODOs
> > piling up.
> > I've been tracking most of them in a Google Doc
> > <
> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1
> >
> > so far, and it's fine for big architectural topics, but for small things
> > it's clearly inadequate.
> >
> > What would you all think if we started to use the main Hibernate Search
> > project to track the small TODOs we have in the Search 6 POC? We would
> > probably have to add some JIRA Components that only make sense in Search
> 6
> > ("indexing", ...), but beyond that I don't think this would cause much
> > trouble.
> > The tickets would all be Tasks targeting version 6, and we could tag them
> > with a new "POC-6.0" component if you think it's necessary. Examples of
> > tasks would be:
> >
> >- Native sorts in the Lucene Sort DSL extension
> ><
> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.1p57dh8ae6d5
> >
> >- Native predicates in the Lucene Predicate DSL extension
> ><
> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.1p57dh8ae6d5
> >
> >- Rework the Lucene DSL implementations to fail fast when parameter
> >conversion errors occur
> ><
> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.xrk3mjaa7k9p
> >
> >- Polish and test Stream indexing (add CompletableFuture returns in
> >particular)
> >- Decide wether to use absolute or relative object path in "nested"
> >search predicates
> >
> > If this feels like too much garbage for the main bug tracker, we can
> create
> > a separate JIRA project instead. But then this will add to the trouble
> > we'll have to go through when merging (commits referring to tickets from
> > another project).
> >
> > Sanne, all, WDYT?
> > --
> > Yoann Rodiere
> > yo...@hibernate.org / yrodi...@redhat.com
> > Software Engineer
> > Hibernate NoORM team
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [HSEARCH][V6-POC] Bug tracking for the Search 6 POC

[Sanne Grinovero]

+1 to create issues in "main" project JIRA

Since JIRA is an issue tracker, some people frown upon its usage as
planning tool. I also don't think it fits too well, especially when we
go too much in detail with upfront planning, but it's not too bad.
Preferrable to yet-another-tool.

I don't think we need to "tag" them as POC-6, it's all the same project.

Thanks,
Sanne




On 5 April 2018 at 08:07, Yoann Rodiere  wrote:
> Hello,
>
> With the Search 6 POC getting closer and closer to something we can merge,
> and thus more and more complex, we are starting to see quite a lot of TODOs
> piling up.
> I've been tracking most of them in a Google Doc
> 
> so far, and it's fine for big architectural topics, but for small things
> it's clearly inadequate.
>
> What would you all think if we started to use the main Hibernate Search
> project to track the small TODOs we have in the Search 6 POC? We would
> probably have to add some JIRA Components that only make sense in Search 6
> ("indexing", ...), but beyond that I don't think this would cause much
> trouble.
> The tickets would all be Tasks targeting version 6, and we could tag them
> with a new "POC-6.0" component if you think it's necessary. Examples of
> tasks would be:
>
>- Native sorts in the Lucene Sort DSL extension
>
> 
>- Native predicates in the Lucene Predicate DSL extension
>
> 
>- Rework the Lucene DSL implementations to fail fast when parameter
>conversion errors occur
>
> 
>- Polish and test Stream indexing (add CompletableFuture returns in
>particular)
>- Decide wether to use absolute or relative object path in "nested"
>search predicates
>
> If this feels like too much garbage for the main bug tracker, we can create
> a separate JIRA project instead. But then this will add to the trouble
> we'll have to go through when merging (commits referring to tickets from
> another project).
>
> Sanne, all, WDYT?
> --
> Yoann Rodiere
> yo...@hibernate.org / yrodi...@redhat.com
> Software Engineer
> Hibernate NoORM team
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev