Mailing List Archive

Oh, and that the CHANGES.txt entries in e.g. 9.9.0 section match on 9.x and
main branches... I think that one we have some automation to catch?

Mike McCandless

http://blog.mikemccandless.com


On Wed, Nov 29, 2023 at 5:58?AM Michael McCandless <
lucene@mikemccandless.com> wrote:

> Hi Team,
>
> I see Chris is tagging issues that were left open after their linked PRs
> were merged (thanks!).
>
> Is there something in our release tooling that cross-checks all the weakly
> linked metadata today: Milestone marked (or more often: not) on an issue vs
> commits to the respective branches vs location in Lucene's CHANGES.txt vs
> open/closed issue matching the linked PRs?
>
> It seems like some simple automation here could catch mistakes. E.g. I'm
> uncertain I properly moved all the FST related CHANGES.txt entries to the
> right places.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>

Well, I created a starting tool to at least help us keep the
what-should-be-identical-yet-is-nearly-impossible-for-us-to-achieve
sections in CHANGES.txt in sync: https://github.com/apache/lucene/pull/12860

Right now it finds a number of mostly minor differences in the 9.9.0
sections in main vs branch_9_9:

NOTE: resolving branch_9_9 -->
https://raw.githubusercontent.com/apache/lucene/branch_9_9/lucene/CHANGES.txt
NOTE: resolving main -->
https://raw.githubusercontent.com/apache/lucene/main/lucene/CHANGES.txt
15a16,18
> * GITHUB#12646, GITHUB#12690: Move FST#addNode to FSTCompiler to avoid a
circular dependency
> between FST and FSTCompiler (Anh Dung Bui)
>
27,30c30
< * GITHUB#12646, GITHUB#12690: Move FST#addNode to FSTCompiler to avoid a
circular dependency
< between FST and FSTCompiler (Anh Dung Bui)
<
< * GITHUB#12709 Consolidate FSTStore and BytesStore in FST. Created
FSTReader which contains the common methods
---
> * GITHUB#12709: Consolidate FSTStore and BytesStore in FST. Created
FSTReader which contains the common methods
33,34d32
< * GITHUB#12735: Remove FSTCompiler#getTermCount() and
FSTCompiler.UnCompiledNode#inputCount (Anh Dung Bui)
<
37a36,37
> * GITHUB#12735: Remove FSTCompiler#getTermCount() and
FSTCompiler.UnCompiledNode#inputCount (Anh Dung Bui)
>
166a167,168
> * GITHUB#12748: Specialize arc store for continuous label in FST. (Guo
Feng, Zhang Chao)
>
173,177d174
< * GITHUB#12748: Specialize arc store for continuous label in FST. (Guo
Feng, Chao Zhang)
<
< * GITHUB#12825, GITHUB#12834: Hunspell: improved dictionary loading
performance, allowed in-memory entry sorting.
< (Peter Gromov)
<
185,186d181
<
< * GITHUB#12552: Make FSTPostingsFormat load FSTs off-heap. (Tony X)


Mike McCandless

http://blog.mikemccandless.com


On Wed, Nov 29, 2023 at 6:01?AM Michael McCandless <
lucene@mikemccandless.com> wrote:

> Oh, and that the CHANGES.txt entries in e.g. 9.9.0 section match on 9.x
> and main branches... I think that one we have some automation to catch?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Nov 29, 2023 at 5:58?AM Michael McCandless <
> lucene@mikemccandless.com> wrote:
>
>> Hi Team,
>>
>> I see Chris is tagging issues that were left open after their linked PRs
>> were merged (thanks!).
>>
>> Is there something in our release tooling that cross-checks all the
>> weakly linked metadata today: Milestone marked (or more often: not) on an
>> issue vs commits to the respective branches vs location in Lucene's
>> CHANGES.txt vs open/closed issue matching the linked PRs?
>>
>> It seems like some simple automation here could catch mistakes. E.g. I'm
>> uncertain I properly moved all the FST related CHANGES.txt entries to the
>> right places.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>

Hopefully this is relevant.

There are useful tools like git-cliff? for automating changelog generation.

https://github.com/orhun/git-cliff

Tony X
________________________________
From: Michael McCandless <lucene@mikemccandless.com>
Sent: Thursday, November 30, 2023 4:30 AM
To: dev@lucene.apache.org <dev@lucene.apache.org>
Subject: Re: GitHub issues vs PRs vs Lucene's CHANGES.txt

Well, I created a starting tool to at least help us keep the what-should-be-identical-yet-is-nearly-impossible-for-us-to-achieve sections in CHANGES.txt in sync: https://github.com/apache/lucene/pull/12860

Right now it finds a number of mostly minor differences in the 9.9.0 sections in main vs branch_9_9:

NOTE: resolving branch_9_9 --> https://raw.githubusercontent.com/apache/lucene/branch_9_9/lucene/CHANGES.txt
NOTE: resolving main --> https://raw.githubusercontent.com/apache/lucene/main/lucene/CHANGES.txt
15a16,18
> * GITHUB#12646, GITHUB#12690: Move FST#addNode to FSTCompiler to avoid a circular dependency
> between FST and FSTCompiler (Anh Dung Bui)
>
27,30c30
< * GITHUB#12646, GITHUB#12690: Move FST#addNode to FSTCompiler to avoid a circular dependency
< between FST and FSTCompiler (Anh Dung Bui)
<
< * GITHUB#12709 Consolidate FSTStore and BytesStore in FST. Created FSTReader which contains the common methods
---
> * GITHUB#12709: Consolidate FSTStore and BytesStore in FST. Created FSTReader which contains the common methods
33,34d32
< * GITHUB#12735: Remove FSTCompiler#getTermCount() and FSTCompiler.UnCompiledNode#inputCount (Anh Dung Bui)
<
37a36,37
> * GITHUB#12735: Remove FSTCompiler#getTermCount() and FSTCompiler.UnCompiledNode#inputCount (Anh Dung Bui)
>
166a167,168
> * GITHUB#12748: Specialize arc store for continuous label in FST. (Guo Feng, Zhang Chao)
>
173,177d174
< * GITHUB#12748: Specialize arc store for continuous label in FST. (Guo Feng, Chao Zhang)
<
< * GITHUB#12825, GITHUB#12834: Hunspell: improved dictionary loading performance, allowed in-memory entry sorting.
< (Peter Gromov)
<
185,186d181
<
< * GITHUB#12552: Make FSTPostingsFormat load FSTs off-heap. (Tony X)


Mike McCandless

http://blog.mikemccandless.com


On Wed, Nov 29, 2023 at 6:01?AM Michael McCandless <lucene@mikemccandless.com<mailto:lucene@mikemccandless.com>> wrote:
Oh, and that the CHANGES.txt entries in e.g. 9.9.0 section match on 9.x and main branches... I think that one we have some automation to catch?

Mike McCandless

http://blog.mikemccandless.com


On Wed, Nov 29, 2023 at 5:58?AM Michael McCandless <lucene@mikemccandless.com<mailto:lucene@mikemccandless.com>> wrote:
Hi Team,

I see Chris is tagging issues that were left open after their linked PRs were merged (thanks!).

Is there something in our release tooling that cross-checks all the weakly linked metadata today: Milestone marked (or more often: not) on an issue vs commits to the respective branches vs location in Lucene's CHANGES.txt vs open/closed issue matching the linked PRs?

It seems like some simple automation here could catch mistakes. E.g. I'm uncertain I properly moved all the FST related CHANGES.txt entries to the right places.

Mike McCandless

http://blog.mikemccandless.com

Sounds like we could automate assigning the milestone, given that it is a
commonly forgotten step, based on the section of CHANGES where the PR gets
added?

I am pretty sure that I forgot to add entries to CHANGES too. That could be
maybe suggested in github. Whenever there's a PR that does not touch the
CHANGES.txt, more often than not it's a mistake?

I am wondering if it still makes sense to have to track changes associated
to versions in both milestones as well as the CHANGES.txt file. There is
some duplication there. Could the CHANGES file be generated from the
milestone, if it was set correctly, and the description of the change taken
from the title of the PR? Sorry if I am bringing up something that has been
discussed before.

On Thu, Nov 30, 2023 at 11:03?PM Dongyu Xu <dongyu214@hotmail.com> wrote:

> Hopefully this is relevant.
>
> There are useful tools like git-cliff? for automating changelog
> generation.
>
> https://github.com/orhun/git-cliff
>
> Tony X
> ------------------------------
> *From:* Michael McCandless <lucene@mikemccandless.com>
> *Sent:* Thursday, November 30, 2023 4:30 AM
> *To:* dev@lucene.apache.org <dev@lucene.apache.org>
> *Subject:* Re: GitHub issues vs PRs vs Lucene's CHANGES.txt
>
> Well, I created a starting tool to at least help us keep the
> what-should-be-identical-yet-is-nearly-impossible-for-us-to-achieve
> sections in CHANGES.txt in sync:
> https://github.com/apache/lucene/pull/12860
>
> Right now it finds a number of mostly minor differences in the 9.9.0
> sections in main vs branch_9_9:
>
> NOTE: resolving branch_9_9 -->
> https://raw.githubusercontent.com/apache/lucene/branch_9_9/lucene/CHANGES.txt
> NOTE: resolving main -->
> https://raw.githubusercontent.com/apache/lucene/main/lucene/CHANGES.txt
> 15a16,18
> > * GITHUB#12646, GITHUB#12690: Move FST#addNode to FSTCompiler to avoid a
> circular dependency
> > between FST and FSTCompiler (Anh Dung Bui)
> >
> 27,30c30
> < * GITHUB#12646, GITHUB#12690: Move FST#addNode to FSTCompiler to avoid a
> circular dependency
> < between FST and FSTCompiler (Anh Dung Bui)
> <
> < * GITHUB#12709 Consolidate FSTStore and BytesStore in FST. Created
> FSTReader which contains the common methods
> ---
> > * GITHUB#12709: Consolidate FSTStore and BytesStore in FST. Created
> FSTReader which contains the common methods
> 33,34d32
> < * GITHUB#12735: Remove FSTCompiler#getTermCount() and
> FSTCompiler.UnCompiledNode#inputCount (Anh Dung Bui)
> <
> 37a36,37
> > * GITHUB#12735: Remove FSTCompiler#getTermCount() and
> FSTCompiler.UnCompiledNode#inputCount (Anh Dung Bui)
> >
> 166a167,168
> > * GITHUB#12748: Specialize arc store for continuous label in FST. (Guo
> Feng, Zhang Chao)
> >
> 173,177d174
> < * GITHUB#12748: Specialize arc store for continuous label in FST. (Guo
> Feng, Chao Zhang)
> <
> < * GITHUB#12825, GITHUB#12834: Hunspell: improved dictionary loading
> performance, allowed in-memory entry sorting.
> < (Peter Gromov)
> <
> 185,186d181
> <
> < * GITHUB#12552: Make FSTPostingsFormat load FSTs off-heap. (Tony X)
>
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Nov 29, 2023 at 6:01?AM Michael McCandless <
> lucene@mikemccandless.com> wrote:
>
> Oh, and that the CHANGES.txt entries in e.g. 9.9.0 section match on 9.x
> and main branches... I think that one we have some automation to catch?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Nov 29, 2023 at 5:58?AM Michael McCandless <
> lucene@mikemccandless.com> wrote:
>
> Hi Team,
>
> I see Chris is tagging issues that were left open after their linked PRs
> were merged (thanks!).
>
> Is there something in our release tooling that cross-checks all the weakly
> linked metadata today: Milestone marked (or more often: not) on an issue vs
> commits to the respective branches vs location in Lucene's CHANGES.txt vs
> open/closed issue matching the linked PRs?
>
> It seems like some simple automation here could catch mistakes. E.g. I'm
> uncertain I properly moved all the FST related CHANGES.txt entries to the
> right places.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>