Re: Fix version / milestones

[Tomoko Uchida]

A naive solution to enforce Milestone for every pull request would be to
fail Github CI if no milestone is set for that.


on:
  pull_request:
branches:
  - main
types: [synchronize, opened, reopened, milestoned, demilestoned]

jobs:
  check-milestone:
name: Check Milestone
runs-on: ubuntu-latest
steps:
  - if: github.event.pull_request.milestone == null
run: exit 1


But adding this simple CI job to the central repo may introduce a large
amount of noise (it is not exactly a "CI").
A more sophisticated method could be to use Octokit Request Action to
gently remind maintainers to set a Milestone before closing the issue/pr,
though, I've never tried it.
https://github.com/MeilCli/actions/blob/master/.github/workflows/check-has-milestone.yml


2023年5月11日(木) 22:45 Michael McCandless :

> Hi Team,
>
> [spinoff from this java-user thread:
> https://markmail.org/thread/mmx22s7lysxqh6wm]
>
> In the good old Jira days, when we resolved an issue, the workflow
> encouraged us to also mark the Fix Version that this fix will be released
> in.
>
> This metadata is very helpful to future users wanting to know which Lucene
> version has the fix.
>
> GitHub issues/PRs have the Milestone tag instead, but the workflow doesn't
> encourage us to record it, from what I can see.  Looking at our recently
> closed issues (
> https://github.com/apache/lucene/issues?q=is%3Aissue+is%3Aclosed) I can
> see some are tagged with a Milestone, but most are not.
>
> I am furthest from a GitHub expert!  So maybe I'm just missing something
> obvious?  E.g. is it possible via a commit message to "Closes #XXX in
> Milestone YYY"?  Do we just have to rely on "best effort" to remember to
> set a Milestone on an issue when we close it?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>

Re: Subject: New branch and feature freeze for Lucene 9.4.0

[Tomoko Uchida]

> Branch branch_9_4 has been cut and versions updated to 9.5 on stable
branch.

Then the GitHub Milestone for 9.5 also needs to be created.

This time, I created Milestone 9.5.0. We should include it in the release
process.
https://github.com/apache/lucene/milestone/4


2022年9月3日(土) 4:42 Michael Sokolov :

> NOTICE:
>
> Branch branch_9_4 has been cut and versions updated to 9.5 on stable
> branch.
>
> Please observe the normal rules:
>
> * No new features may be committed to the branch.
> * Documentation patches, build patches and serious bug fixes may be
>   committed to the branch. However, you should submit all patches you
>   want to commit to Jira first to give others the chance to review
>   and possibly vote against the patch. Keep in mind that it is our
>   main intention to keep the branch as stable as possible.
> * All patches that are intended for the branch should first be committed
>   to the unstable branch, merged into the stable branch, and then into
>   the current release branch.
> * Normal unstable and stable branch development may continue as usual.
>   However, if you plan to commit a big change to the unstable branch
>   while the branch feature freeze is in effect, think twice: can't the
>   addition wait a couple more days? Merges of bug fixes into the branch
>   may become more difficult.
> * Only Jira issues with Fix version 9.4 and priority "Blocker" will delay
>   a release candidate build.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene 9.4.0 release

[Tomoko Uchida]

Hi Mike,
to be precise, on GitHub I think release managers would go through these
steps:

1. Figure out blocker issues/PRs and associate them with the target
Milestone, e.g., "9.4.0"
2. Create a new Milestone for the next version here
<https://github.com/apache/lucene/milestones>, e.g., "9.5.0"
3. Address blockers - some may be resolved by developers, and others may be
re-associated with the next Milestone.
4. Make release artifacts and publish them as usual.
5. Close (not Delete!) the target Milestone.

You need no special permission on GitHub to handle Milestones, and
everything should be fairly straightforward.
If you need any help, I'd be happy to review the necessary updates on the
release wizard tool. I have little time to make a patch for that myself
right now, sorry.

Tomoko


2022年9月1日(木) 10:02 Tomoko Uchida :

> > One thing is that for JIra, we needed to acquire special permissions in
> order to be able to add new release versions, but I don't think that is
> true for GitHub ...
>
> You do not need any special permissions to make new Milestones on GitHub.
> Every committer already has permission to create/close/delete Milestones,
> you can test it here.
> https://github.com/apache/lucene/milestones
>
> Tomoko
>
>
> 2022年9月1日(木) 9:57 Michael Sokolov :
>
>> I started to go through the release process, which has been scripted very
>> clearly by Jan and others, and found Jira-specific steps there. I think the
>> translations to GitHub will be pretty straightforward. One thing is that
>> for JIra, we needed to acquire special permissions in order to be able to
>> add new release versions, but I don't think that is true for GitHub ... Any
>> committer should be able to do that, right?
>>
>> On Wed, Aug 31, 2022, 8:42 PM Tomoko Uchida 
>> wrote:
>>
>>> Hi Mike,
>>> thanks for your response.
>>>
>>> I'm actually not familiar with the whole release procedure that may be
>>> built on Jira.
>>> I hope other people help to interpret Jira-related things on the way
>>> into the language of GitHub issues.
>>>
>>> Tomoko
>>>
>>> 2022年9月1日(木) 3:40 Michael Sokolov :
>>>
>>>> Thanks for the links, Tomoko. I thought it would be helpful to ask on
>>>> the list in case this new system has not been fully internalized by
>>>> all the developers. And I confess I didn't know about that nice
>>>> milestone view! It makes this very easy, assuming of course that
>>>> everyone follows the guidelines and labels the issues with the
>>>> milestone.
>>>>
>>>> On Wed, Aug 31, 2022 at 11:16 AM Tomoko Uchida
>>>>  wrote:
>>>> >
>>>> > Ok in short, you can find blockers for 9.4.0 here.
>>>> > https://github.com/apache/lucene/milestone/3
>>>> >
>>>> > If there are other issues/PRs that are still not resolved but planned
>>>> to be delivered in 9.4.0, just set their Milestone as 9.4.0. Then they will
>>>> appear in the list.
>>>> >
>>>> >
>>>> >
>>>> > 2022年9月1日(木) 0:00 Tomoko Uchida :
>>>> >>
>>>> >> I believe we decided to use GitHub Milestone for release planning
>>>> and I wrote documentation about it.
>>>> >>
>>>> https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md
>>>> >>
>>>> >> Is this unclear to you?
>>>> >>
>>>> >>
>>>> >> 2022年8月31日(水) 23:13 Michael Sokolov :
>>>> >>>
>>>> >>> Hi, I'd like to start the ball rolling for a 9.4.0 release. We don't
>>>> >>> have a large number of things, but there are a few nice high-impact
>>>> >>> changes; see excerpt from CHANGE.txt below. I'll volunteer to be
>>>> >>> release manager. I'd just like to know if anybody has any
>>>> outstanding
>>>> >>> work that is nearing completion and that they'd like to include,
>>>> >>> and/or if we have any known blocker issues*.
>>>> >>>
>>>> >>> * -- I am having a little trouble searching github for blocker
>>>> issues.
>>>> >>> I think there may not be any, but I tried
>>>> >>>
>>>> https://github.com/apache/lucene/issues?q=is%3Aissue+is%3Aopen+legacy-jira-priority%5C%3AMajor+
>>>> >>> to find Major issues, for example, and it seems to only find one
>>>> Minor
>&

Re: Lucene 9.4.0 release

[Tomoko Uchida]

> One thing is that for JIra, we needed to acquire special permissions in
order to be able to add new release versions, but I don't think that is
true for GitHub ...

You do not need any special permissions to make new Milestones on GitHub.
Every committer already has permission to create/close/delete Milestones,
you can test it here.
https://github.com/apache/lucene/milestones

Tomoko


2022年9月1日(木) 9:57 Michael Sokolov :

> I started to go through the release process, which has been scripted very
> clearly by Jan and others, and found Jira-specific steps there. I think the
> translations to GitHub will be pretty straightforward. One thing is that
> for JIra, we needed to acquire special permissions in order to be able to
> add new release versions, but I don't think that is true for GitHub ... Any
> committer should be able to do that, right?
>
> On Wed, Aug 31, 2022, 8:42 PM Tomoko Uchida 
> wrote:
>
>> Hi Mike,
>> thanks for your response.
>>
>> I'm actually not familiar with the whole release procedure that may be
>> built on Jira.
>> I hope other people help to interpret Jira-related things on the way into
>> the language of GitHub issues.
>>
>> Tomoko
>>
>> 2022年9月1日(木) 3:40 Michael Sokolov :
>>
>>> Thanks for the links, Tomoko. I thought it would be helpful to ask on
>>> the list in case this new system has not been fully internalized by
>>> all the developers. And I confess I didn't know about that nice
>>> milestone view! It makes this very easy, assuming of course that
>>> everyone follows the guidelines and labels the issues with the
>>> milestone.
>>>
>>> On Wed, Aug 31, 2022 at 11:16 AM Tomoko Uchida
>>>  wrote:
>>> >
>>> > Ok in short, you can find blockers for 9.4.0 here.
>>> > https://github.com/apache/lucene/milestone/3
>>> >
>>> > If there are other issues/PRs that are still not resolved but planned
>>> to be delivered in 9.4.0, just set their Milestone as 9.4.0. Then they will
>>> appear in the list.
>>> >
>>> >
>>> >
>>> > 2022年9月1日(木) 0:00 Tomoko Uchida :
>>> >>
>>> >> I believe we decided to use GitHub Milestone for release planning and
>>> I wrote documentation about it.
>>> >>
>>> https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md
>>> >>
>>> >> Is this unclear to you?
>>> >>
>>> >>
>>> >> 2022年8月31日(水) 23:13 Michael Sokolov :
>>> >>>
>>> >>> Hi, I'd like to start the ball rolling for a 9.4.0 release. We don't
>>> >>> have a large number of things, but there are a few nice high-impact
>>> >>> changes; see excerpt from CHANGE.txt below. I'll volunteer to be
>>> >>> release manager. I'd just like to know if anybody has any outstanding
>>> >>> work that is nearing completion and that they'd like to include,
>>> >>> and/or if we have any known blocker issues*.
>>> >>>
>>> >>> * -- I am having a little trouble searching github for blocker
>>> issues.
>>> >>> I think there may not be any, but I tried
>>> >>>
>>> https://github.com/apache/lucene/issues?q=is%3Aissue+is%3Aopen+legacy-jira-priority%5C%3AMajor+
>>> >>> to find Major issues, for example, and it seems to only find one
>>> Minor
>>> >>> one? Does anyone have better github-search-fu?
>>> >>>
>>> >>> API Changes
>>> >>> -
>>> >>> * LUCENE-10577: Add VectorEncoding to enable byte-encoded HNSW
>>> vectors
>>> >>> (Michael Sokolov, Julie Tibshirani)
>>> >>>
>>> >>> New Features
>>> >>> -
>>> >>> * LUCENE-10654: Add new ShapeDocValuesField for LatLonShape and
>>> >>> XYShape. (Nick Knize)
>>> >>>
>>> >>> * LUCENE-10629: Support match set filtering with a query in
>>> >>> MatchingFacetSetCounts. (Stefan Vodita, Shai Erera)
>>> >>>
>>> >>> * LUCENE-10633: SortField#setOptimizeSortWithIndexedData and
>>> >>>   SortField#getOptimizeSortWithIndexedData were introduce to provide
>>> >>>   an option to disable sort optimization for various sort fields.
>>> >>> (Mayya Sharipova)
>>> >>>
>>> >>> Improvements
>>> 

Re: Lucene 9.4.0 release

[Tomoko Uchida]

Hi Mike,
thanks for your response.

I'm actually not familiar with the whole release procedure that may be
built on Jira.
I hope other people help to interpret Jira-related things on the way into
the language of GitHub issues.

Tomoko

2022年9月1日(木) 3:40 Michael Sokolov :

> Thanks for the links, Tomoko. I thought it would be helpful to ask on
> the list in case this new system has not been fully internalized by
> all the developers. And I confess I didn't know about that nice
> milestone view! It makes this very easy, assuming of course that
> everyone follows the guidelines and labels the issues with the
> milestone.
>
> On Wed, Aug 31, 2022 at 11:16 AM Tomoko Uchida
>  wrote:
> >
> > Ok in short, you can find blockers for 9.4.0 here.
> > https://github.com/apache/lucene/milestone/3
> >
> > If there are other issues/PRs that are still not resolved but planned to
> be delivered in 9.4.0, just set their Milestone as 9.4.0. Then they will
> appear in the list.
> >
> >
> >
> > 2022年9月1日(木) 0:00 Tomoko Uchida :
> >>
> >> I believe we decided to use GitHub Milestone for release planning and I
> wrote documentation about it.
> >>
> https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md
> >>
> >> Is this unclear to you?
> >>
> >>
> >> 2022年8月31日(水) 23:13 Michael Sokolov :
> >>>
> >>> Hi, I'd like to start the ball rolling for a 9.4.0 release. We don't
> >>> have a large number of things, but there are a few nice high-impact
> >>> changes; see excerpt from CHANGE.txt below. I'll volunteer to be
> >>> release manager. I'd just like to know if anybody has any outstanding
> >>> work that is nearing completion and that they'd like to include,
> >>> and/or if we have any known blocker issues*.
> >>>
> >>> * -- I am having a little trouble searching github for blocker issues.
> >>> I think there may not be any, but I tried
> >>>
> https://github.com/apache/lucene/issues?q=is%3Aissue+is%3Aopen+legacy-jira-priority%5C%3AMajor+
> >>> to find Major issues, for example, and it seems to only find one Minor
> >>> one? Does anyone have better github-search-fu?
> >>>
> >>> API Changes
> >>> -
> >>> * LUCENE-10577: Add VectorEncoding to enable byte-encoded HNSW vectors
> >>> (Michael Sokolov, Julie Tibshirani)
> >>>
> >>> New Features
> >>> -
> >>> * LUCENE-10654: Add new ShapeDocValuesField for LatLonShape and
> >>> XYShape. (Nick Knize)
> >>>
> >>> * LUCENE-10629: Support match set filtering with a query in
> >>> MatchingFacetSetCounts. (Stefan Vodita, Shai Erera)
> >>>
> >>> * LUCENE-10633: SortField#setOptimizeSortWithIndexedData and
> >>>   SortField#getOptimizeSortWithIndexedData were introduce to provide
> >>>   an option to disable sort optimization for various sort fields.
> >>> (Mayya Sharipova)
> >>>
> >>> Improvements
> >>> -
> >>> * LUCENE-10592: Build HNSW Graph on indexing. (Mayya Sharipova, Adrien
> >>> Grand, Julie Tibshirani)
> >>>
> >>> * GITHUB#11715: Add Integer awareness to RamUsageEstimator.sizeOf
> (Mike Drob)
> >>>
> >>> Optimizations
> >>> -
> >>>
> >>> * LUCENE-10661: Reduce memory copy in BytesStore. (luyuncheng)
> >>>
> >>> * GITHUB#1020: Support #scoreSupplier and small optimizations to
> >>> DocValuesRewriteMethod. (Greg Miller)
> >>>
> >>> * LUCENE-10633: Added support for dynamic pruning to queries sorted by
> a string
> >>>   field that is indexed with terms and SORTED or SORTED_SET doc values.
> >>>   (Adrien Grand)
> >>>
> >>> * LUCENE-10627: Using ByteBuffersDataInput reduce memory copy on
> >>> compressing data. (luyuncheng)
> >>>
> >>> * GITHUB#1062: Optimize TermInSetQuery when a term is present that
> >>> matches all docs in a segment.
> >>>   (Greg Miller)
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene 9.4.0 release

[Tomoko Uchida]

Ok in short, you can find blockers for 9.4.0 here.
https://github.com/apache/lucene/milestone/3

If there are other issues/PRs that are still not resolved but planned to be
delivered in 9.4.0, just set their Milestone as 9.4.0. Then they will
appear in the list.



2022年9月1日(木) 0:00 Tomoko Uchida :

> I believe we decided to use GitHub Milestone for release planning and I
> wrote documentation about it.
> https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md
>
> Is this unclear to you?
>
>
> 2022年8月31日(水) 23:13 Michael Sokolov :
>
>> Hi, I'd like to start the ball rolling for a 9.4.0 release. We don't
>> have a large number of things, but there are a few nice high-impact
>> changes; see excerpt from CHANGE.txt below. I'll volunteer to be
>> release manager. I'd just like to know if anybody has any outstanding
>> work that is nearing completion and that they'd like to include,
>> and/or if we have any known blocker issues*.
>>
>> * -- I am having a little trouble searching github for blocker issues.
>> I think there may not be any, but I tried
>>
>> https://github.com/apache/lucene/issues?q=is%3Aissue+is%3Aopen+legacy-jira-priority%5C%3AMajor+
>> to find Major issues, for example, and it seems to only find one Minor
>> one? Does anyone have better github-search-fu?
>>
>> API Changes
>> -
>> * LUCENE-10577: Add VectorEncoding to enable byte-encoded HNSW vectors
>> (Michael Sokolov, Julie Tibshirani)
>>
>> New Features
>> -
>> * LUCENE-10654: Add new ShapeDocValuesField for LatLonShape and
>> XYShape. (Nick Knize)
>>
>> * LUCENE-10629: Support match set filtering with a query in
>> MatchingFacetSetCounts. (Stefan Vodita, Shai Erera)
>>
>> * LUCENE-10633: SortField#setOptimizeSortWithIndexedData and
>>   SortField#getOptimizeSortWithIndexedData were introduce to provide
>>   an option to disable sort optimization for various sort fields.
>> (Mayya Sharipova)
>>
>> Improvements
>> -
>> * LUCENE-10592: Build HNSW Graph on indexing. (Mayya Sharipova, Adrien
>> Grand, Julie Tibshirani)
>>
>> * GITHUB#11715: Add Integer awareness to RamUsageEstimator.sizeOf (Mike
>> Drob)
>>
>> Optimizations
>> -
>>
>> * LUCENE-10661: Reduce memory copy in BytesStore. (luyuncheng)
>>
>> * GITHUB#1020: Support #scoreSupplier and small optimizations to
>> DocValuesRewriteMethod. (Greg Miller)
>>
>> * LUCENE-10633: Added support for dynamic pruning to queries sorted by a
>> string
>>   field that is indexed with terms and SORTED or SORTED_SET doc values.
>>   (Adrien Grand)
>>
>> * LUCENE-10627: Using ByteBuffersDataInput reduce memory copy on
>> compressing data. (luyuncheng)
>>
>> * GITHUB#1062: Optimize TermInSetQuery when a term is present that
>> matches all docs in a segment.
>>   (Greg Miller)
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Lucene 9.4.0 release

[Tomoko Uchida]

I believe we decided to use GitHub Milestone for release planning and I
wrote documentation about it.
https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md

Is this unclear to you?


2022年8月31日(水) 23:13 Michael Sokolov :

> Hi, I'd like to start the ball rolling for a 9.4.0 release. We don't
> have a large number of things, but there are a few nice high-impact
> changes; see excerpt from CHANGE.txt below. I'll volunteer to be
> release manager. I'd just like to know if anybody has any outstanding
> work that is nearing completion and that they'd like to include,
> and/or if we have any known blocker issues*.
>
> * -- I am having a little trouble searching github for blocker issues.
> I think there may not be any, but I tried
>
> https://github.com/apache/lucene/issues?q=is%3Aissue+is%3Aopen+legacy-jira-priority%5C%3AMajor+
> to find Major issues, for example, and it seems to only find one Minor
> one? Does anyone have better github-search-fu?
>
> API Changes
> -
> * LUCENE-10577: Add VectorEncoding to enable byte-encoded HNSW vectors
> (Michael Sokolov, Julie Tibshirani)
>
> New Features
> -
> * LUCENE-10654: Add new ShapeDocValuesField for LatLonShape and
> XYShape. (Nick Knize)
>
> * LUCENE-10629: Support match set filtering with a query in
> MatchingFacetSetCounts. (Stefan Vodita, Shai Erera)
>
> * LUCENE-10633: SortField#setOptimizeSortWithIndexedData and
>   SortField#getOptimizeSortWithIndexedData were introduce to provide
>   an option to disable sort optimization for various sort fields.
> (Mayya Sharipova)
>
> Improvements
> -
> * LUCENE-10592: Build HNSW Graph on indexing. (Mayya Sharipova, Adrien
> Grand, Julie Tibshirani)
>
> * GITHUB#11715: Add Integer awareness to RamUsageEstimator.sizeOf (Mike
> Drob)
>
> Optimizations
> -
>
> * LUCENE-10661: Reduce memory copy in BytesStore. (luyuncheng)
>
> * GITHUB#1020: Support #scoreSupplier and small optimizations to
> DocValuesRewriteMethod. (Greg Miller)
>
> * LUCENE-10633: Added support for dynamic pruning to queries sorted by a
> string
>   field that is indexed with terms and SORTED or SORTED_SET doc values.
>   (Adrien Grand)
>
> * LUCENE-10627: Using ByteBuffersDataInput reduce memory copy on
> compressing data. (luyuncheng)
>
> * GITHUB#1062: Optimize TermInSetQuery when a term is present that
> matches all docs in a segment.
>   (Greg Miller)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [ANNOUNCE] Issue migration Jira to GitHub starts on Monday, August 22

[Tomoko Uchida]

> Given how many difficult aspects there were on the way, you can probably
offer jira-github transition services and make them your business! :)

I think once is enough; will do anything but that...

Tomoko


2022年8月29日(月) 20:58 Dawid Weiss :

>
> Congratulations, Tomoko. It's really well done.
>
> Given how many difficult aspects there were on the way, you can probably
> offer jira-github transition services and make them your business! :)
>
> Dawid
>
> On Mon, Aug 29, 2022 at 1:22 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
>> We have completed all the necessary post-processing and cleanups.
>> Thank you everyone, who is involved in this; hope the outcome meets our
>> requirements and serves for future development.
>>
>> Again, if you need guidelines for our new issue tracking system, please
>> review these docs.
>> - Contributing guide:
>> https://github.com/apache/lucene/blob/main/CONTRIBUTING.md
>> - GitHub issues how-to:
>> https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md
>>
>> Tomoko
>>
>>
>> 2022年8月28日(日) 21:28 Uwe Schindler :
>>
>> > Hi,
>> >
>> > Works fine. I got many, many mails to my private address for the issues
>> I
>> > did during heavy Java 5 Migration in 2009. 浪
>> >
>> > It also sends mails for long closed issues. This is questionable but
>> fine
>> > for consistency. If asked before I would have been +/-0 pro or con this.
>> >
>> > I think it was important to send the message, as this informs people
>> where
>> > a possible discussion also for closed issues proceeds.
>> >
>> > Uwe
>> >
>> > Am 28. August 2022 13:03:53 MESZ schrieb Tomoko Uchida <
>> > tomoko.uchida.1...@gmail.com>:
>> >>
>> >> 
>> >>
>> >> Jira notification to issues@ was stopped.
>> >> I'm going to run the script to add this comment to each Jira issue
>> today.
>> >>
>> >> """
>> >> This issue was moved to GitHub issue: > >> issue>.
>> >> """
>> >>
>> >> Issue reporters and watchers still receive Jira updates; this is fine
>> to
>> >> let people know the issue was moved to GitHub.
>> >> It's Sunday. Convenient for me to run the script that can send lots of
>> >> emails (to people who are involved in Jira issues.)
>> >>
>> >> Tomoko
>> >>
>> >>
>> >> 2022年8月26日(金) 23:06 Tomoko Uchida :
>> >>
>> >>> > This works well, but we should maybe change the CHANGES.txt perl
>> >>> script to always link using the URL pattern "/issue/" instead of
>> "/pull/".
>> >>> I think "issue" is the more generic term (I see PR as a special case
>> of
>> >>> issue).
>> >>>
>> >>> Yes, the path should be "/issue". I'll make the change.
>> >>>
>> >>> Tomoko
>> >>>
>> >>>
>> >>> 2022年8月26日(金) 22:33 Uwe Schindler :
>> >>>
>> >>>> Hi Tomoko,
>> >>>>
>> >>>> I also tested that the links in CHANGES.txt also work with issues.
>> That
>> >>>> is confirmed. Baysically for Github there's an automatic redirect if
>> you
>> >>>> link to an ID as PR and in reality it is an issue:
>> >>>>
>> >>>> E.g.,
>> >>>>
>> https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc/changes/Changes.html
>> ;
>> >>>> see 9.4, bugfix 5. It has the link
>> >>>>
>> >>>>1. LUCENE-10665 <
>> http://issues.apache.org/jira/browse/LUCENE-10665>,
>> >>>> GITHUB#11701 <https://github.com/apache/lucene/pull/11701>: Fix
>> >>>>classloading deadlock in analysis factories / AnalysisSPILoader
>> >>>>initialization.
>> >>>>(Uwe Schindler)
>> >>>>
>> >>>> This works well, but we should maybe change the CHANGES.txt perl
>> script
>> >>>> to always link using the URL pattern "/issue/" instead of "/pull/".
>> I think
>> >>>> "issue" is the more generic term (I see PR as a special case of
>> issue).
>> >>>>
>> >>>> The PR to change this would 

Re: [ANNOUNCE] Issue migration Jira to GitHub starts on Monday, August 22

[Tomoko Uchida]

We have completed all the necessary post-processing and cleanups.
Thank you everyone, who is involved in this; hope the outcome meets our
requirements and serves for future development.

Again, if you need guidelines for our new issue tracking system, please
review these docs.
- Contributing guide:
https://github.com/apache/lucene/blob/main/CONTRIBUTING.md
- GitHub issues how-to:
https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md

Tomoko


2022年8月28日(日) 21:28 Uwe Schindler :

> Hi,
>
> Works fine. I got many, many mails to my private address for the issues I
> did during heavy Java 5 Migration in 2009. 浪
>
> It also sends mails for long closed issues. This is questionable but fine
> for consistency. If asked before I would have been +/-0 pro or con this.
>
> I think it was important to send the message, as this informs people where
> a possible discussion also for closed issues proceeds.
>
> Uwe
>
> Am 28. August 2022 13:03:53 MESZ schrieb Tomoko Uchida <
> tomoko.uchida.1...@gmail.com>:
>>
>> 
>>
>> Jira notification to issues@ was stopped.
>> I'm going to run the script to add this comment to each Jira issue today.
>>
>> """
>> This issue was moved to GitHub issue: > issue>.
>> """
>>
>> Issue reporters and watchers still receive Jira updates; this is fine to
>> let people know the issue was moved to GitHub.
>> It's Sunday. Convenient for me to run the script that can send lots of
>> emails (to people who are involved in Jira issues.)
>>
>> Tomoko
>>
>>
>> 2022年8月26日(金) 23:06 Tomoko Uchida :
>>
>>> > This works well, but we should maybe change the CHANGES.txt perl
>>> script to always link using the URL pattern "/issue/" instead of "/pull/".
>>> I think "issue" is the more generic term (I see PR as a special case of
>>> issue).
>>>
>>> Yes, the path should be "/issue". I'll make the change.
>>>
>>> Tomoko
>>>
>>>
>>> 2022年8月26日(金) 22:33 Uwe Schindler :
>>>
>>>> Hi Tomoko,
>>>>
>>>> I also tested that the links in CHANGES.txt also work with issues. That
>>>> is confirmed. Baysically for Github there's an automatic redirect if you
>>>> link to an ID as PR and in reality it is an issue:
>>>>
>>>> E.g.,
>>>> https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc/changes/Changes.html;
>>>> see 9.4, bugfix 5. It has the link
>>>>
>>>>1. LUCENE-10665 <http://issues.apache.org/jira/browse/LUCENE-10665>,
>>>> GITHUB#11701 <https://github.com/apache/lucene/pull/11701>: Fix
>>>>classloading deadlock in analysis factories / AnalysisSPILoader
>>>>initialization.
>>>>(Uwe Schindler)
>>>>
>>>> This works well, but we should maybe change the CHANGES.txt perl script
>>>> to always link using the URL pattern "/issue/" instead of "/pull/". I think
>>>> "issue" is the more generic term (I see PR as a special case of issue).
>>>>
>>>> The PR to change this would be a one-liner.
>>>>
>>>> Uwe
>>>>
>>>> Am 26.08.2022 um 04:09 schrieb Tomoko Uchida:
>>>>
>>>> Hi Uwe,
>>>> thanks for testing.
>>>>
>>>> > But now my question: To contact the original bug submitter I acnt do
>>>> > anything in JIRA anymore. That's fine, but when do we add the
>>>> automated
>>>> > message to all issues with a reference to the new Github URL? This
>>>> would
>>>> > help to inform the user like "now look here user looks github and
>>>> > sees: issue resolved".
>>>>
>>>> The script is already ready, but I think we need to silence Jira
>>>> notifications to issues@ before that.
>>>> Only Jira admins can change the notification schema. I am waiting for
>>>> https://issues.apache.org/jira/browse/INFRA-23625 is resolved.
>>>>
>>>> Tomoko
>>>>
>>>>
>>>> 2022年8月26日(金) 1:35 Uwe Schindler :
>>>>
>>>>> Hi Tomoko!
>>>>>
>>>>> Great and works well! I also tested backporting with cherry-picks on
>>>>> issue https://github.com/apache/lucene/issues/11701:
>>>>>
>>>>> - The linked PR (https://github.com/apache/lucene/pull/11718) was
>>

Re: [ANNOUNCE] Issue migration Jira to GitHub starts on Monday, August 22

[Tomoko Uchida]

Jira notification to issues@ was stopped.
I'm going to run the script to add this comment to each Jira issue today.

"""
This issue was moved to GitHub issue: .
"""

Issue reporters and watchers still receive Jira updates; this is fine to
let people know the issue was moved to GitHub.
It's Sunday. Convenient for me to run the script that can send lots of
emails (to people who are involved in Jira issues.)

Tomoko


2022年8月26日(金) 23:06 Tomoko Uchida :

> > This works well, but we should maybe change the CHANGES.txt perl script
> to always link using the URL pattern "/issue/" instead of "/pull/". I think
> "issue" is the more generic term (I see PR as a special case of issue).
>
> Yes, the path should be "/issue". I'll make the change.
>
> Tomoko
>
>
> 2022年8月26日(金) 22:33 Uwe Schindler :
>
>> Hi Tomoko,
>>
>> I also tested that the links in CHANGES.txt also work with issues. That
>> is confirmed. Baysically for Github there's an automatic redirect if you
>> link to an ID as PR and in reality it is an issue:
>>
>> E.g.,
>> https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc/changes/Changes.html;
>> see 9.4, bugfix 5. It has the link
>>
>>1. LUCENE-10665 <http://issues.apache.org/jira/browse/LUCENE-10665>,
>>GITHUB#11701 <https://github.com/apache/lucene/pull/11701>: Fix
>>classloading deadlock in analysis factories / AnalysisSPILoader
>>initialization.
>>(Uwe Schindler)
>>
>> This works well, but we should maybe change the CHANGES.txt perl script
>> to always link using the URL pattern "/issue/" instead of "/pull/". I think
>> "issue" is the more generic term (I see PR as a special case of issue).
>>
>> The PR to change this would be a one-liner.
>>
>> Uwe
>>
>> Am 26.08.2022 um 04:09 schrieb Tomoko Uchida:
>>
>> Hi Uwe,
>> thanks for testing.
>>
>> > But now my question: To contact the original bug submitter I acnt do
>> > anything in JIRA anymore. That's fine, but when do we add the automated
>> > message to all issues with a reference to the new Github URL? This would
>> > help to inform the user like "now look here user looks github and
>> > sees: issue resolved".
>>
>> The script is already ready, but I think we need to silence Jira
>> notifications to issues@ before that.
>> Only Jira admins can change the notification schema. I am waiting for
>> https://issues.apache.org/jira/browse/INFRA-23625 is resolved.
>>
>> Tomoko
>>
>>
>> 2022年8月26日(金) 1:35 Uwe Schindler :
>>
>>> Hi Tomoko!
>>>
>>> Great and works well! I also tested backporting with cherry-picks on
>>> issue https://github.com/apache/lucene/issues/11701:
>>>
>>> - The linked PR (https://github.com/apache/lucene/pull/11718) was main
>>> only. In the squash merge message I added "This fixes #11701."
>>>
>>> - After merging the PR the related issue was closed too (standard
>>> behaviour)
>>>
>>> - I then used my desktop machine and cherry picked the squash commit
>>> using my TortoiseGit by opening log, switching to main branch, right
>>> clicking the commit and choose cherry pick. This went throough without
>>> any problems.
>>>
>>> - The merge commit was successfully also linked in both the PR and the
>>> issue.
>>>
>>> So all works as it should. No need to create separate PRs for 9.x. I
>>> look into backporting https://github.com/apache/lucene/issues/11701 to
>>> 8.11 branch (if the original author responds). Of course ten the links
>>> won't work unless you add repo name.
>>>
>>> But now my question: To contact the original bug submitter I acnt do
>>> anything in JIRA anymore. That's fine, but when do we add the automated
>>> message to all issues with a reference to the new Github URL? This would
>>> help to inform the user like "now look here user looks github and
>>> sees: issue resolved".
>>>
>>> Uwe
>>>
>>> Am 25.08.2022 um 13:04 schrieb Dawid Weiss:
>>> > It looks great, thank you for this monumental effort, Tomoko.
>>> >
>>> > Dawid
>>> >
>>> > On Wed, Aug 24, 2022 at 9:19 PM Tomoko Uchida
>>> >  wrote:
>>> >> 
>>> >>
>>> >> Issue migration has been completed (except for minor cleanups).
>>> >> This is 

Clarification about mentions in CHANGES

[Tomoko Uchida]

Hi all.

Now we fully support GItHub issues, you can mention Issue numbers as well
as PR numbers in lucene/CHANGES.txt
.
You can mention both issues and PRs in CHANGES.txt by GITHUB#NN. NN is
either an issue number or a PR number.

>From a broader viewpoint, there are no differences between issues and pull
requests. You can associate both issues and PRs with Milestones/Labels and
mention both issues and PRs in the CHANGES in the very same manner.
Sometimes a pull request would be sufficient, and sometimes you may want to
open an issue and PRs on it, depending on the context. [1]

[1]
https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md#should-i-raise-an-issue-when-i-already-have-a-working-patch

Tomoko

To committers: Use Milestones for release planning

[Tomoko Uchida]

Hi devs,

We use Milestone for release planning in GitHub instead of issue labels.
The change was suggested/discussed in a recent mail thread [1].

In short,

1. Use Milestone for release planning. An issue/PR can have only one
Milestone.
2. Do not use JIra-style "fix-versoin" label.

If an Issue/PR should be delivered in 9.4.0, mark it as Milestone 9.4.0; if
it should be delivered in 10.0.0, mark it as Milestone 10.0.0; if the
delivery version is not determined yet, do nothing.

E.g.,
Milestone 10.0.0: https://github.com/apache/lucene/milestone/2
Milestone 9.4.0: https://github.com/apache/lucene/milestone/3

See GitHub issue how-to

for general guidelines, please.

[1] https://lists.apache.org/thread/b2xsx02wswzjzs5dzkox9njv4t8t1vf5

Tomoko

Re: [ANNOUNCE] Issue migration Jira to GitHub starts on Monday, August 22

[Tomoko Uchida]

> This works well, but we should maybe change the CHANGES.txt perl script
to always link using the URL pattern "/issue/" instead of "/pull/". I think
"issue" is the more generic term (I see PR as a special case of issue).

Yes, the path should be "/issue". I'll make the change.

Tomoko


2022年8月26日(金) 22:33 Uwe Schindler :

> Hi Tomoko,
>
> I also tested that the links in CHANGES.txt also work with issues. That is
> confirmed. Baysically for Github there's an automatic redirect if you link
> to an ID as PR and in reality it is an issue:
>
> E.g.,
> https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc/changes/Changes.html;
> see 9.4, bugfix 5. It has the link
>
>1. LUCENE-10665 <http://issues.apache.org/jira/browse/LUCENE-10665>,
>GITHUB#11701 <https://github.com/apache/lucene/pull/11701>: Fix
>classloading deadlock in analysis factories / AnalysisSPILoader
>initialization.
>(Uwe Schindler)
>
> This works well, but we should maybe change the CHANGES.txt perl script to
> always link using the URL pattern "/issue/" instead of "/pull/". I think
> "issue" is the more generic term (I see PR as a special case of issue).
>
> The PR to change this would be a one-liner.
>
> Uwe
>
> Am 26.08.2022 um 04:09 schrieb Tomoko Uchida:
>
> Hi Uwe,
> thanks for testing.
>
> > But now my question: To contact the original bug submitter I acnt do
> > anything in JIRA anymore. That's fine, but when do we add the automated
> > message to all issues with a reference to the new Github URL? This would
> > help to inform the user like "now look here user looks github and
> > sees: issue resolved".
>
> The script is already ready, but I think we need to silence Jira
> notifications to issues@ before that.
> Only Jira admins can change the notification schema. I am waiting for
> https://issues.apache.org/jira/browse/INFRA-23625 is resolved.
>
> Tomoko
>
>
> 2022年8月26日(金) 1:35 Uwe Schindler :
>
>> Hi Tomoko!
>>
>> Great and works well! I also tested backporting with cherry-picks on
>> issue https://github.com/apache/lucene/issues/11701:
>>
>> - The linked PR (https://github.com/apache/lucene/pull/11718) was main
>> only. In the squash merge message I added "This fixes #11701."
>>
>> - After merging the PR the related issue was closed too (standard
>> behaviour)
>>
>> - I then used my desktop machine and cherry picked the squash commit
>> using my TortoiseGit by opening log, switching to main branch, right
>> clicking the commit and choose cherry pick. This went throough without
>> any problems.
>>
>> - The merge commit was successfully also linked in both the PR and the
>> issue.
>>
>> So all works as it should. No need to create separate PRs for 9.x. I
>> look into backporting https://github.com/apache/lucene/issues/11701 to
>> 8.11 branch (if the original author responds). Of course ten the links
>> won't work unless you add repo name.
>>
>> But now my question: To contact the original bug submitter I acnt do
>> anything in JIRA anymore. That's fine, but when do we add the automated
>> message to all issues with a reference to the new Github URL? This would
>> help to inform the user like "now look here user looks github and
>> sees: issue resolved".
>>
>> Uwe
>>
>> Am 25.08.2022 um 13:04 schrieb Dawid Weiss:
>> > It looks great, thank you for this monumental effort, Tomoko.
>> >
>> > Dawid
>> >
>> > On Wed, Aug 24, 2022 at 9:19 PM Tomoko Uchida
>> >  wrote:
>> >> 
>> >>
>> >> Issue migration has been completed (except for minor cleanups).
>> >> This is the Jira -> GitHub issue number mapping for possible future
>> usage.
>> >>
>> https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/issue-map.csv.20220823_final
>> >>
>> >> GitHub issue is now fully available for all issues.
>> >> For issue label management (e.g. "fix-version"), please review this
>> manual.
>> >>
>> https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md
>> >>
>> >> Tomoko
>> >>
>> >>
>> >> 2022年8月22日(月) 19:46 Michael McCandless :
>> >>
>> >>> Wooot!  Thank you so much Tomoko!!
>> >>>
>> >>> Mike
>> >>>
>> >>> On Mon, Aug 22, 2022 at 6:44 AM Tomoko Uchida <
>> 

Re: Label vs. Milestone for version management?

[Tomoko Uchida]

I opened a PR to propose Milestone for release planning.
https://github.com/apache/lucene/pull/11723

Version management is one of the most important things for an
issue-tracking system. Is this clear to everyone?

```
## Milestones

We use Milestones for release planning.

A milestone represents a release. All issues/PRs associated with a
milestone must be resolved before the release, which means unresolved
issues/PRs in a milestone are blockers for the release.

Release managers should consider how to address blockers. Some may be
resolved by developers, and others may be postponed to future releases.

Once the release is done, the Milestone should be closed then a new
Milestone for the next release should be created.
```


Tomoko


2022年8月26日(金) 19:03 Tomoko Uchida :

> Hi,
> it looks like many people favor Milestone over Label? Then I would like to
> bring my proposal utilizing Milestone for version management up again.
>
> A draft plan in my mind:
> - A Milestone represents a release. E.g. Milestone 9.4.0 includes all
> changes in version 9.4.0.
> - Associate issues/PRs to a Milestone where the changes should be
> delivered.
> - Use Milestone for release planning. All issues that are associated with
> a Milestone must be resolved before the release.
>   - If there are unresolved issues in a Milestone, they are blockers for
> the release.
>
> If this looks fine to you, I will do all the necessary things.
> - Create a Milestone for 9.4.0.
> - Associate issues/PRs that are labeled "fix-version:9.4" with Milestone
> 9.4.0.
> - Rename all "fix-version:x.x.x" label to "legacy-jira-fix-verison:x.x.x"
> to avoid possible confusion.
> - Rewrite documentation about release planning.
>
> I will wait for a while for further comments and suggestions, then proceed
> with it next week.
>
> Tomoko
>
>
> 2022年8月26日(金) 6:50 Dawid Weiss :
>
>> About the milestones being single-valued - we already have this
>> single-value notion in changes.txt, don't we? We add a note about the
>> issue to the "last" branch an issue was backported to. I agree
>> sometimes it could be more complicated (vide openjdk, where issues are
>> backported selectively to a few branches or fixed just on a historical
>> branch) but in Lucene things seem to follow a simpler, single-value
>> "milestone+later branches" model.
>>
>> Dawid
>>
>> On Thu, Aug 25, 2022 at 6:40 PM Uwe Schindler  wrote:
>> >
>> > Hi,
>> >
>> > In addition, once you have done a release, you can close the milestone
>> with the date of release and this would mark all those issues as
>> "delivered". So quick filters won't show them anymore. And for the RM it is
>> great to get a list of issues form the Milestones page. If you also use the
>> "release" feature in github it will create nice lists with date of relaese,
>> all fixed issues,... (but we have changes.txt and we don't do releases with
>> Github so it won't be useful, I just mention this).
>> >
>> > I use that in forbiddenapis since long time (also for the pull
>> requests). But I also create my own markdown changes list there (because it
>> looks nicer and you can give more informationlike adding credits).
>> >
>> > Uwe
>> >
>> > Am 25.08.2022 um 17:05 schrieb Houston Putman:
>> >
>> > So the Solr Operator has been using Github Issues for a few releases
>> now, and the Milestone feature has worked really well for a blockers list.
>> >
>> > I agree that it should not be the canonical list of things that were
>> included in that release (although it will likely be very close), but it is
>> very good for easily seeing what PRs/Issues are still open for a particular
>> version.
>> > You can also see the milestone in the Issues & PR list, so it's easy to
>> see what version the Issues/PRs are targeted for at a quick glance.
>> >
>> > - Houston
>> >
>> > On Thu, Aug 25, 2022 at 10:12 AM Robert Muir  wrote:
>> >>
>> >> On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov 
>> wrote:
>> >> >
>> >> > I agree; I've always used CHANGES for a quick historical view. What
>> >> > about the release manager use case? I haven't done a release, but I
>> >> > think we generally want to know if people are targeting changes for
>> an
>> >> > upcoming release, especially if they are blockers. We could just use
>> >> > email to find out about these, but I think it's better if we can look
>> >> > them up in the issue db.
>> >>
>> >> Mark them as priority blocker with a tag? that's all you could do with
>> >> JIRA, too.
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> > --
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > https://www.thetaphi.de
>> > eMail: u...@thetaphi.de
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Label vs. Milestone for version management?

[Tomoko Uchida]

Hi,
it looks like many people favor Milestone over Label? Then I would like to
bring my proposal utilizing Milestone for version management up again.

A draft plan in my mind:
- A Milestone represents a release. E.g. Milestone 9.4.0 includes all
changes in version 9.4.0.
- Associate issues/PRs to a Milestone where the changes should be delivered.
- Use Milestone for release planning. All issues that are associated with a
Milestone must be resolved before the release.
  - If there are unresolved issues in a Milestone, they are blockers for
the release.

If this looks fine to you, I will do all the necessary things.
- Create a Milestone for 9.4.0.
- Associate issues/PRs that are labeled "fix-version:9.4" with Milestone
9.4.0.
- Rename all "fix-version:x.x.x" label to "legacy-jira-fix-verison:x.x.x"
to avoid possible confusion.
- Rewrite documentation about release planning.

I will wait for a while for further comments and suggestions, then proceed
with it next week.

Tomoko


2022年8月26日(金) 6:50 Dawid Weiss :

> About the milestones being single-valued - we already have this
> single-value notion in changes.txt, don't we? We add a note about the
> issue to the "last" branch an issue was backported to. I agree
> sometimes it could be more complicated (vide openjdk, where issues are
> backported selectively to a few branches or fixed just on a historical
> branch) but in Lucene things seem to follow a simpler, single-value
> "milestone+later branches" model.
>
> Dawid
>
> On Thu, Aug 25, 2022 at 6:40 PM Uwe Schindler  wrote:
> >
> > Hi,
> >
> > In addition, once you have done a release, you can close the milestone
> with the date of release and this would mark all those issues as
> "delivered". So quick filters won't show them anymore. And for the RM it is
> great to get a list of issues form the Milestones page. If you also use the
> "release" feature in github it will create nice lists with date of relaese,
> all fixed issues,... (but we have changes.txt and we don't do releases with
> Github so it won't be useful, I just mention this).
> >
> > I use that in forbiddenapis since long time (also for the pull
> requests). But I also create my own markdown changes list there (because it
> looks nicer and you can give more informationlike adding credits).
> >
> > Uwe
> >
> > Am 25.08.2022 um 17:05 schrieb Houston Putman:
> >
> > So the Solr Operator has been using Github Issues for a few releases
> now, and the Milestone feature has worked really well for a blockers list.
> >
> > I agree that it should not be the canonical list of things that were
> included in that release (although it will likely be very close), but it is
> very good for easily seeing what PRs/Issues are still open for a particular
> version.
> > You can also see the milestone in the Issues & PR list, so it's easy to
> see what version the Issues/PRs are targeted for at a quick glance.
> >
> > - Houston
> >
> > On Thu, Aug 25, 2022 at 10:12 AM Robert Muir  wrote:
> >>
> >> On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov 
> wrote:
> >> >
> >> > I agree; I've always used CHANGES for a quick historical view. What
> >> > about the release manager use case? I haven't done a release, but I
> >> > think we generally want to know if people are targeting changes for an
> >> > upcoming release, especially if they are blockers. We could just use
> >> > email to find out about these, but I think it's better if we can look
> >> > them up in the issue db.
> >>
> >> Mark them as priority blocker with a tag? that's all you could do with
> >> JIRA, too.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> > --
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [ANNOUNCE] Issue migration Jira to GitHub starts on Monday, August 22

[Tomoko Uchida]

Hi Uwe,
thanks for testing.

> But now my question: To contact the original bug submitter I acnt do
> anything in JIRA anymore. That's fine, but when do we add the automated
> message to all issues with a reference to the new Github URL? This would
> help to inform the user like "now look here user looks github and
> sees: issue resolved".

The script is already ready, but I think we need to silence Jira
notifications to issues@ before that.
Only Jira admins can change the notification schema. I am waiting for
https://issues.apache.org/jira/browse/INFRA-23625 is resolved.

Tomoko


2022年8月26日(金) 1:35 Uwe Schindler :

> Hi Tomoko!
>
> Great and works well! I also tested backporting with cherry-picks on
> issue https://github.com/apache/lucene/issues/11701:
>
> - The linked PR (https://github.com/apache/lucene/pull/11718) was main
> only. In the squash merge message I added "This fixes #11701."
>
> - After merging the PR the related issue was closed too (standard
> behaviour)
>
> - I then used my desktop machine and cherry picked the squash commit
> using my TortoiseGit by opening log, switching to main branch, right
> clicking the commit and choose cherry pick. This went throough without
> any problems.
>
> - The merge commit was successfully also linked in both the PR and the
> issue.
>
> So all works as it should. No need to create separate PRs for 9.x. I
> look into backporting https://github.com/apache/lucene/issues/11701 to
> 8.11 branch (if the original author responds). Of course ten the links
> won't work unless you add repo name.
>
> But now my question: To contact the original bug submitter I acnt do
> anything in JIRA anymore. That's fine, but when do we add the automated
> message to all issues with a reference to the new Github URL? This would
> help to inform the user like "now look here user looks github and
> sees: issue resolved".
>
> Uwe
>
> Am 25.08.2022 um 13:04 schrieb Dawid Weiss:
> > It looks great, thank you for this monumental effort, Tomoko.
> >
> > Dawid
> >
> > On Wed, Aug 24, 2022 at 9:19 PM Tomoko Uchida
> >  wrote:
> >> 
> >>
> >> Issue migration has been completed (except for minor cleanups).
> >> This is the Jira -> GitHub issue number mapping for possible future
> usage.
> >>
> https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/issue-map.csv.20220823_final
> >>
> >> GitHub issue is now fully available for all issues.
> >> For issue label management (e.g. "fix-version"), please review this
> manual.
> >>
> https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md
> >>
> >> Tomoko
> >>
> >>
> >> 2022年8月22日(月) 19:46 Michael McCandless :
> >>
> >>> Wooot!  Thank you so much Tomoko!!
> >>>
> >>> Mike
> >>>
> >>> On Mon, Aug 22, 2022 at 6:44 AM Tomoko Uchida <
> >>> tomoko.uchida.1...@gmail.com> wrote:
> >>>
> >>>> 
> >>>>
> >>>> Issue migration has been started. Jira is now read-only.
> >>>>
> >>>> GitHub issue is available for new issues.
> >>>>
> >>>> - You should open new issues on GitHub. E.g.
> >>>> https://github.com/apache/lucene/issues/1078
> >>>> - Do not touch issues that are in the middle of migration, please.
> E.g.
> >>>> https://github.com/apache/lucene/issues/1072
> >>>>- While you cannot break these issues, migration scripts can
> >>>> modify/overwrite your comments on the issues.
> >>>> - Pull requests are not affected. You can open/update PRs as usual.
> >>>> Please let me know if you have any trouble with PRs.
> >>>>
> >>>>
> >>>> Tomoko
> >>>>
> >>>>
> >>>> 2022年8月18日(木) 18:23 Tomoko Uchida :
> >>>>
> >>>>> Hello all,
> >>>>>
> >>>>> The Lucene project decided to move our issue tracking system from
> Jira
> >>>>> to GitHub and migrate all Jira issues to GitHub.
> >>>>>
> >>>>> We start issue migration on Monday, August 22 at 8:00 UTC.
> >>>>> 1) We make Jira read-only before migration. You cannot update
> existing
> >>>>> issues until the migration is completed.
> >>>>> 2) You can use GitHub for opening NEW issues or 

Re: Label vs. Milestone for version management?

[Tomoko Uchida]

For now, please use Label "fix-version:x.x.x" for version management as
written in
https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md.

In other words,

1. Use
fix-version:10.0
<https://github.com/apache/lucene/issues?q=label%3Afix-version%3A10.0+> for
main branch.
fix-version:9.4
<https://github.com/apache/lucene/issues?q=label%3Afix-version%3A9.4> for
9.x branch.

2. Do not use Milestone.
I removed Milestone 9.4.0. Sorry, we need a clear convention and
instructions about it. Milestone is fine with me, but we should avoid any
confusion unless we gain consensus on introducing it.

Feel free to push it forward if you would like, please.

Tomoko


2022年8月25日(木) 16:47 Tomoko Uchida :

> Hi all.
>
> I once proposed using Milestone for version management in GitHub before
> the issue migration.
> The proposal did not gain any support, so I thought we concluded that we
> use "fix-version" Label for issue/PR version management.
>
> But it looks like there are suggestions to use Milestone.
> What should we do?
>
> Tomoko
>

Label vs. Milestone for version management?

[Tomoko Uchida]

Hi all.

I once proposed using Milestone for version management in GitHub before the
issue migration.
The proposal did not gain any support, so I thought we concluded that we
use "fix-version" Label for issue/PR version management.

But it looks like there are suggestions to use Milestone.
What should we do?

Tomoko

Re: [ANNOUNCE] Issue migration Jira to GitHub starts on Monday, August 22

[Tomoko Uchida]

Issue migration has been completed (except for minor cleanups).
This is the Jira -> GitHub issue number mapping for possible future usage.
https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/issue-map.csv.20220823_final

GitHub issue is now fully available for all issues.
For issue label management (e.g. "fix-version"), please review this manual.
https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md

Tomoko


2022年8月22日(月) 19:46 Michael McCandless :

> Wooot!  Thank you so much Tomoko!!
>
> Mike
>
> On Mon, Aug 22, 2022 at 6:44 AM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
>> 
>>
>> Issue migration has been started. Jira is now read-only.
>>
>> GitHub issue is available for new issues.
>>
>> - You should open new issues on GitHub. E.g.
>> https://github.com/apache/lucene/issues/1078
>> - Do not touch issues that are in the middle of migration, please. E.g.
>> https://github.com/apache/lucene/issues/1072
>>   - While you cannot break these issues, migration scripts can
>> modify/overwrite your comments on the issues.
>> - Pull requests are not affected. You can open/update PRs as usual.
>> Please let me know if you have any trouble with PRs.
>>
>>
>> Tomoko
>>
>>
>> 2022年8月18日(木) 18:23 Tomoko Uchida :
>>
>>> Hello all,
>>>
>>> The Lucene project decided to move our issue tracking system from Jira
>>> to GitHub and migrate all Jira issues to GitHub.
>>>
>>> We start issue migration on Monday, August 22 at 8:00 UTC.
>>> 1) We make Jira read-only before migration. You cannot update existing
>>> issues until the migration is completed.
>>> 2) You can use GitHub for opening NEW issues or pull requests during
>>> migration.
>>>
>>> Note that issues should be raised in Jira at this moment, although
>>> GitHub issue is already enabled in the Lucene repository.
>>> Please do not raise issues in GitHub until we let you know that GitHub
>>> issue is officially available. We immediately close any issues on GitHub
>>> until then.
>>>
>>> Here are the detailed plan/migration steps.
>>> https://github.com/apache/lucene-jira-archive/issues/7
>>>
>>> Tomoko
>>>
>> --
> Mike McCandless
>
> http://blog.mikemccandless.com
>

Re: [ANNOUNCE] Issue migration Jira to GitHub starts on Monday, August 22

[Tomoko Uchida]

Issue migration has been started. Jira is now read-only.

GitHub issue is available for new issues.

- You should open new issues on GitHub. E.g.
https://github.com/apache/lucene/issues/1078
- Do not touch issues that are in the middle of migration, please. E.g.
https://github.com/apache/lucene/issues/1072
  - While you cannot break these issues, migration scripts can
modify/overwrite your comments on the issues.
- Pull requests are not affected. You can open/update PRs as usual. Please
let me know if you have any trouble with PRs.


Tomoko


2022年8月18日(木) 18:23 Tomoko Uchida :

> Hello all,
>
> The Lucene project decided to move our issue tracking system from Jira to
> GitHub and migrate all Jira issues to GitHub.
>
> We start issue migration on Monday, August 22 at 8:00 UTC.
> 1) We make Jira read-only before migration. You cannot update existing
> issues until the migration is completed.
> 2) You can use GitHub for opening NEW issues or pull requests during
> migration.
>
> Note that issues should be raised in Jira at this moment, although GitHub
> issue is already enabled in the Lucene repository.
> Please do not raise issues in GitHub until we let you know that GitHub
> issue is officially available. We immediately close any issues on GitHub
> until then.
>
> Here are the detailed plan/migration steps.
> https://github.com/apache/lucene-jira-archive/issues/7
>
> Tomoko
>

[ANNOUNCE] Issue migration Jira to GitHub starts on Monday, August 22

[Tomoko Uchida]

Hello all,

The Lucene project decided to move our issue tracking system from Jira to
GitHub and migrate all Jira issues to GitHub.

We start issue migration on Monday, August 22 at 8:00 UTC.
1) We make Jira read-only before migration. You cannot update existing
issues until the migration is completed.
2) You can use GitHub for opening NEW issues or pull requests during
migration.

Note that issues should be raised in Jira at this moment, although GitHub
issue is already enabled in the Lucene repository.
Please do not raise issues in GitHub until we let you know that GitHub
issue is officially available. We immediately close any issues on GitHub
until then.

Here are the detailed plan/migration steps.
https://github.com/apache/lucene-jira-archive/issues/7

Tomoko

Re: [HELP] Link your Apache Lucene Jira and GitHub account ids before Thursday August 4 midnight (in your local time)

[Tomoko Uchida]

Thanks Elliot,
added:
https://github.com/apache/lucene-jira-archive/commit/6baddb9bb7fd0cacf39eda8409cc24758ec87722


2022年8月16日(火) 9:00 Elliot Lin :

> elelliot,elliotzlin,Elliot Lin
>
> On Mon, Aug 15, 2022 at 4:02 AM Marios Trivyzas  wrote:
>
>> Many thanks!
>>
>> On Mon, Aug 15, 2022 at 2:00 PM Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>> Thanks Marios, I added you here:
>>> https://github.com/apache/lucene-jira-archive/commit/c74c1517127ce4a4ba6780edfcb7da2099ab5bf0
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Mon, Aug 15, 2022 at 4:38 AM Marios Trivyzas 
>>> wrote:
>>>
 matriv,matriv,Marios Trivyzas

 On Wed, Aug 10, 2022 at 1:15 AM Michael McCandless <
 luc...@mikemccandless.com> wrote:

> Thanks Ilan, I added both your Jira accounts mapped to the same GitHub
> account:
> https://github.com/apache/lucene-jira-archive/commit/a424bc88439db36cd427a5d3d676d26131878f94
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Aug 9, 2022 at 5:37 PM Ilan Ginzburg 
> wrote:
>
>> Jira: ilan
>> GitHub: murblanc
>>
>> (used to have murblanc as Jira id as well and changed to Ilan when I
>> became Solr/Lucene commiter).
>>
>> On Tue, Aug 9, 2022, 5:36 PM Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>> OK, added!  Thanks:
>>>
>>>
>>> https://github.com/apache/lucene-jira-archive/commit/efd7c510749ada4841eed714a5f7f817bb11c8cf
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Mon, Aug 8, 2022 at 1:09 PM Walter Underwood <
>>> wun...@wunderwood.org> wrote:
>>>
 JiraName,GitHubAccount,JiraDispName
 wunder,wrunderwood,Walter Underwood

 wunder
 Walter Underwood
 wun...@wunderwood.org
 http://observer.wunderwood.org/  (my blog)

 On Aug 6, 2022, at 3:05 AM, Michael McCandless <
 luc...@mikemccandless.com> wrote:

 Hi Adam, I added your linked accounts here:

 https://github.com/apache/lucene-jira-archive/commit/c228cb184c073f4b96cd68d45a000cf390455b7c

 And Tomoko added Rushabh's linked accounts here:


 https://github.com/apache/lucene-jira-archive/commit/6f9501ec68792c1b287e93770f7a9dfd351b86fb

 Keep the linked accounts coming!

 Mike

 On Thu, Aug 4, 2022 at 7:02 PM Rushabh Shah <
 rushabh.s...@salesforce.com.invalid> wrote:

> Hi,
> My mapping is:
> JiraName,GitHubAccount,JiraDispName
> shahrs87, shahrs87, Rushabh Shah
>
> Thank you Tomoko and Mike for all of your hard work.
>
>
>
>
> On Sun, Jul 31, 2022 at 3:08 AM Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> Hello Lucene users, contributors and developers,
>>
>> If you have used Lucene's Jira and you have a GitHub account as
>> well, please check whether your user id mapping is in this file:
>> https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified
>>
>> If not, please reply to this email and we will try to add you.
>>
>> Please forward this email to anyone you know might be impacted
>> and who might not be tracking the Lucene lists.
>>
>>
>> Full details:
>>
>> The Lucene project will soon migrate from Jira to GitHub for
>> issue tracking.
>>
>> There have been discussions, votes, a migration tool created /
>> iterated (thanks to Tomoko Uchida's incredibly hard work), all 
>> iterating on
>> Lucene's dev list.
>>
>> When we run the migration, we would like to map Jira users to the
>> right GitHub users to properly @-mention the right person and make it
>> easier for you to find issues you have engaged with.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
> --
 Mike McCandless

 http://blog.mikemccandless.com




 --
 Marios

>>>
>>
>> --
>> Marios
>>
>

The way to silence Jira notifications?

[Tomoko Uchida]

Hi,
I wonder if perhaps there is anyone who knows the way to completely silence
Jira notifications (during issue migration).
I see the notification settings in Lucene Jira but can't really test it.

Thanks,
Tomoko

Re: [HELP] Please spot-check the migrated Lucene GitHub issues!

[Tomoko Uchida]

> This one https://github.com/mocobeta/forks-migration-test-2/issues/8964
> seems to be missing its attachment - not sure if this was expected
> with this round? EG

Yes, I need to explain it.
Currently, all attachments are disappeared since I just moved all
attachments to another branch ("gh-pages") to use GitHub Pages for hosting
static contents (images, etc.)
https://github.com/apache/lucene-jira-archive/pull/141

On the actual migration, all attachments should be correctly shown/ able to
be downloaded.
e.g.) https://github.com/mocobeta/forks-migration-test-2/issues/10628
(LUCENE-9004)

Tomoko

2022年8月9日(火) 20:49 Michael Sokolov :

> Yes, looks amazing! All I could find was:
>
> This one https://github.com/mocobeta/forks-migration-test-2/issues/8964
> seems to be missing its attachment - not sure if this was expected
> with this round? EG
>
> https://raw.githubusercontent.com/apache/lucene-jira-archive/attachments/attachments/LUCENE-9004/hnsw_layered_graph.png
> gives a 404. I know you were planning to use GH pages instead of that
> raw content stuff, so I guess this should be resolved with another
> round? Although I'm a bit surprised that the attachment would have
> disappeared
>
> On Tue, Aug 9, 2022 at 6:56 AM Uwe Schindler  wrote:
> >
> > Hi Tomoko,
> >
> > this looks all great! Go ahead and thanks for taking care. I will follow
> the INFRA issue during my vacation.
> >
> > Uwe
> >
> > Am 08.08.2022 um 17:42 schrieb Tomoko Uchida:
> >
> > Hi,
> > this is the latest iteration of the migrations test.
> > https://github.com/mocobeta/forks-migration-test-2/issues
> >
> > I fixed a few conversion errors I noticed on that, but there should
> remain glitches that are relatively easy to fix I didn't notice.
> > Please pick one or two of your memorial issues and if they are correctly
> converted into Markdown (i.e. can be used as references for future usage)
> when you have some time.
> >
> > We cannot iterate the time-consuming test forever. I plan to run the
> final iteration this week.
> >
> > Tomoko
> >
> >
> > 2022年7月31日(日) 18:21 Michael McCandless :
> >>
> >> On Sat, Jul 30, 2022 at 8:47 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
> >>
> >>> > Is it intentional that we do not set Assignees on migration?
> >>>
> >>> You can assign a GitHub account only when it has push access to the
> repository; it was infeasible to give push access to all committers to the
> test repo (an invite/accept flow is needed for each committer).
> >>> Assignees will be set when the actual migration on apache/lucene repo
> - every assignee in Jira should have push access to it.
> >>
> >>
> >> Woops OK thanks Tomoko!  I think you explained this already at least
> two times now, sorry ;)
> >>
> >> Mike McCandless
> >>
> >> http://blog.mikemccandless.com
> >
> > --
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [HELP] Please spot-check the migrated Lucene GitHub issues!

[Tomoko Uchida]

> Or did we make that improvement after you generated this latest version
maybe?

Yes. The latest walk-through test was done three days ago before this was
merged.
https://github.com/apache/lucene-jira-archive/pull/128 (2 days ago)

Tomoko


2022年8月9日(火) 2:49 Michael McCandless :

> Hi Tomoko,
>
> I had thought that we improved the "Legacy Jira: by..." wording, but I
> still see e.g.:]
>
> [Legacy Jira: by Steven Rowe (@sarowe) on Apr 26 2013]
>
> Or did we make that improvement after you generated this latest version
> maybe?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Mon, Aug 8, 2022 at 11:43 AM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
>> Hi,
>> this is the latest iteration of the migrations test.
>> https://github.com/mocobeta/forks-migration-test-2/issues
>>
>> I fixed a few conversion errors I noticed on that, but there should
>> remain glitches that are relatively easy to fix I didn't notice.
>> Please pick one or two of your memorial issues and if they are correctly
>> converted into Markdown (i.e. can be used as references for future usage)
>> when you have some time.
>>
>> We cannot iterate the time-consuming test forever. I plan to run the
>> final iteration this week.
>>
>> Tomoko
>>
>>
>> 2022年7月31日(日) 18:21 Michael McCandless :
>>
>>> On Sat, Jul 30, 2022 at 8:47 PM Tomoko Uchida <
>>> tomoko.uchida.1...@gmail.com> wrote:
>>>
>>> > Is it intentional that we do not set Assignees on migration?
>>>>
>>>> You can assign a GitHub account only when it has push access to the
>>>> repository; it was infeasible to give push access to all committers to the
>>>> test repo (an invite/accept flow is needed for each committer).
>>>> Assignees will be set when the actual migration on apache/lucene repo -
>>>> every assignee in Jira should have push access to it.
>>>>
>>>
>>> Woops OK thanks Tomoko!  I think you explained this already at least two
>>> times now, sorry ;)
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>>
>>>>

Re: [HELP] Please spot-check the migrated Lucene GitHub issues!

[Tomoko Uchida]

Hi,
this is the latest iteration of the migrations test.
https://github.com/mocobeta/forks-migration-test-2/issues

I fixed a few conversion errors I noticed on that, but there should remain
glitches that are relatively easy to fix I didn't notice.
Please pick one or two of your memorial issues and if they are correctly
converted into Markdown (i.e. can be used as references for future usage)
when you have some time.

We cannot iterate the time-consuming test forever. I plan to run the final
iteration this week.

Tomoko


2022年7月31日(日) 18:21 Michael McCandless :

> On Sat, Jul 30, 2022 at 8:47 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
> > Is it intentional that we do not set Assignees on migration?
>>
>> You can assign a GitHub account only when it has push access to the
>> repository; it was infeasible to give push access to all committers to the
>> test repo (an invite/accept flow is needed for each committer).
>> Assignees will be set when the actual migration on apache/lucene repo -
>> every assignee in Jira should have push access to it.
>>
>
> Woops OK thanks Tomoko!  I think you explained this already at least two
> times now, sorry ;)
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>>
>>

Re: [HELP] Link your Apache Lucene Jira and GitHub account ids before Thursday August 4 midnight (in your local time)

[Tomoko Uchida]

Understood. I added your account to the mapping:
https://github.com/apache/lucene-jira-archive/commit/bbaf23ddc329470346546f2acac5b80eda503aca
If you open issues or make comments in Jira before the issue migration,
your contribution will be associated with your GH account.

Tomoko


2022年8月7日(日) 14:41 Aditya Varun Chadha :

> Thanks Tomoko,
> There is no activity in JIRA from me as far as I can recall. This is the
> correct and only account though.
>
> On Sun 7. Aug 2022 at 05:50, Tomoko Uchida 
> wrote:
>
> > Hi Aditya,
> > I found a Jira user "adichad" but this account has no activities in
> Lucene
> > Jira. See:
> > https://issues.apache.org/jira/secure/ViewProfile.jspa?name=adichad
> >
> > I wonder if you have multiple Jira accounts and you use another account
> for
> > Lucene? For example, there is a Jira user "abakle
> > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=abakle>" -
> > this has activities in LUCENE.
> >
> > Tomoko
> >
> >
> > 2022年8月7日(日) 5:56 Aditya Varun Chadha :
> >
> > > JIRA: adichad
> > > GitHub: adichad
> > >
> > > Thank you!
> > >
> > > On Sat 6. Aug 2022 at 20:37, Glen Newton 
> wrote:
> > >
> > > > jira: gnewton
> > > > github: gnewton  (github.com/gnewton)
> > > >
> > > > Thanks,
> > > > Glen
> > > >
> > > >
> > > >
> > > > On Sat, 6 Aug 2022 at 14:11, Tomoko Uchida <
> > tomoko.uchida.1...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Hi everyone.
> > > > >
> > > > > I wanted to let you know that we'll extend the deadline until the
> > date
> > > > the
> > > > > migration is started (the date is not fixed yet).
> > > > > Please let us know your Jira/Github usernames if you don't see
> > > mapping(s)
> > > > > for your account in this file:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified
> > > > >
> > > > > Tomoko
> > > > >
> > > > >
> > > > > 2022年8月7日(日) 1:36 Baris Kazar :
> > > > >
> > > > > > Thank You Thank You
> > > > > > Best regards
> > > > > > 
> > > > > > From: Michael McCandless 
> > > > > > Sent: Saturday, August 6, 2022 11:29:25 AM
> > > > > > To: Baris Kazar 
> > > > > > Cc: java-u...@lucene.apache.org 
> > > > > > Subject: Re: [HELP] Link your Apache Lucene Jira and GitHub
> account
> > > ids
> > > > > > before Thursday August 4 midnight (in your local time)
> > > > > >
> > > > > > OK done:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/lucene-jira-archive/commit/13fa4cb46a1a6d609448240e4f66c263da8b3fd1
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://github.com/apache/lucene-jira-archive/commit/13fa4cb46a1a6d609448240e4f66c263da8b3fd1__;!!ACWV5N9M2RV99hQ!OJffdSKrjdfY7VYGcAVGsx4rKHPICvgac4eOcXOf1fnT7u9fJ2RSu9toYPgowHx72UC33Ixg1s1BLKR6GBFgnw$
> > > > > > >
> > > > > >
> > > > > > Mike McCandless
> > > > > >
> > > > > > http://blog.mikemccandless.com<
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__http://blog.mikemccandless.com__;!!ACWV5N9M2RV99hQ!OJffdSKrjdfY7VYGcAVGsx4rKHPICvgac4eOcXOf1fnT7u9fJ2RSu9toYPgowHx72UC33Ixg1s1BLKQULWvYcw$
> > > > > > >
> > > > > >
> > > > > >
> > > > > > On Sat, Aug 6, 2022 at 10:29 AM Baris Kazar <
> > baris.ka...@oracle.com
> > > > > > <mailto:baris.ka...@oracle.com>> wrote:
> > > > > > I think so.
> > > > > > Best regards
> > > > > > 
> > > > > > From: Michael McCandless  > > > > > luc...@mikemccandless.com>>
> > > > > > Sent: Saturday, August 6, 2022 10:12 AM
> > > > > > To

Make both Jira and GitHub issues/PRs read-only during issue migration

[Tomoko Uchida]

Hi everyone.
This is an announcement for a change in the coming migration for our issue
system.

I first thought we'd keep our issue system available during migration (and
made a plan not to introduce downtime).
However, there are a couple of suggestions and discussions in an issue
 to completely
non-writable both Jira and GitHub until the migration is completed to avoid
any inconsistency or accidents; I generally agree with that for safety.

Allowing downtime, the migration will proceed as follows:

   1. Make both Jira and GitHub read-only for everyone except for the
   accounts that are used in the migration. We'd need to forbid PRs as well as
   issues since pull requests are just special issues in GitHub.
   2. Start migration. This would take ~72 hours.
   3. Make GitHub issues and PRs writable once the migration is completed.
   4. Make Jira writable (only for committers or me, if possible).
   5. Add each Jira issue a comment saying "This was moved to GitHub [URL]".
   6. Make Jira read-only.

The arrangements in detail will be determined with the infra team, but I
first wanted to share the change with devs.
The plan is not fixed yet, and there are still uncertainties in access
control to me. If you have objections or suggestions about the plan, please
reply to this mail.

Thanks,
Tomoko

Re: [HELP] Link your Apache Lucene Jira and GitHub account ids before Thursday August 4 midnight (in your local time)

[Tomoko Uchida]

Hi Aditya,
I found a Jira user "adichad" but this account has no activities in Lucene
Jira. See:
https://issues.apache.org/jira/secure/ViewProfile.jspa?name=adichad

I wonder if you have multiple Jira accounts and you use another account for
Lucene? For example, there is a Jira user "abakle
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=abakle>" -
this has activities in LUCENE.

Tomoko


2022年8月7日(日) 5:56 Aditya Varun Chadha :

> JIRA: adichad
> GitHub: adichad
>
> Thank you!
>
> On Sat 6. Aug 2022 at 20:37, Glen Newton  wrote:
>
> > jira: gnewton
> > github: gnewton  (github.com/gnewton)
> >
> > Thanks,
> > Glen
> >
> >
> >
> > On Sat, 6 Aug 2022 at 14:11, Tomoko Uchida  >
> > wrote:
> >
> > > Hi everyone.
> > >
> > > I wanted to let you know that we'll extend the deadline until the date
> > the
> > > migration is started (the date is not fixed yet).
> > > Please let us know your Jira/Github usernames if you don't see
> mapping(s)
> > > for your account in this file:
> > >
> > >
> >
> https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified
> > >
> > > Tomoko
> > >
> > >
> > > 2022年8月7日(日) 1:36 Baris Kazar :
> > >
> > > > Thank You Thank You
> > > > Best regards
> > > > 
> > > > From: Michael McCandless 
> > > > Sent: Saturday, August 6, 2022 11:29:25 AM
> > > > To: Baris Kazar 
> > > > Cc: java-u...@lucene.apache.org 
> > > > Subject: Re: [HELP] Link your Apache Lucene Jira and GitHub account
> ids
> > > > before Thursday August 4 midnight (in your local time)
> > > >
> > > > OK done:
> > > >
> > >
> >
> https://github.com/apache/lucene-jira-archive/commit/13fa4cb46a1a6d609448240e4f66c263da8b3fd1
> > > > <
> > > >
> > >
> >
> https://urldefense.com/v3/__https://github.com/apache/lucene-jira-archive/commit/13fa4cb46a1a6d609448240e4f66c263da8b3fd1__;!!ACWV5N9M2RV99hQ!OJffdSKrjdfY7VYGcAVGsx4rKHPICvgac4eOcXOf1fnT7u9fJ2RSu9toYPgowHx72UC33Ixg1s1BLKR6GBFgnw$
> > > > >
> > > >
> > > > Mike McCandless
> > > >
> > > > http://blog.mikemccandless.com<
> > > >
> > >
> >
> https://urldefense.com/v3/__http://blog.mikemccandless.com__;!!ACWV5N9M2RV99hQ!OJffdSKrjdfY7VYGcAVGsx4rKHPICvgac4eOcXOf1fnT7u9fJ2RSu9toYPgowHx72UC33Ixg1s1BLKQULWvYcw$
> > > > >
> > > >
> > > >
> > > > On Sat, Aug 6, 2022 at 10:29 AM Baris Kazar  > > > <mailto:baris.ka...@oracle.com>> wrote:
> > > > I think so.
> > > > Best regards
> > > > 
> > > > From: Michael McCandless  > > > luc...@mikemccandless.com>>
> > > > Sent: Saturday, August 6, 2022 10:12 AM
> > > > To: java-u...@lucene.apache.org<mailto:java-u...@lucene.apache.org>
> <
> > > > java-u...@lucene.apache.org<mailto:java-u...@lucene.apache.org>>
> > > > Cc: Baris Kazar  baris.ka...@oracle.com
> > >>
> > > > Subject: Re: [HELP] Link your Apache Lucene Jira and GitHub account
> ids
> > > > before Thursday August 4 midnight (in your local time)
> > > >
> > > > Thanks Baris,
> > > >
> > > > And your Jira ID is bkazar right?
> > > >
> > > > Mike
> > > >
> > > > On Sat, Aug 6, 2022 at 10:05 AM Baris Kazar  > > > <mailto:baris.ka...@oracle.com>> wrote:
> > > > My github username is bmkazar
> > > > can You please register me?
> > > > Best regards
> > > > 
> > > > From: Michael McCandless  > > > luc...@mikemccandless.com>>
> > > > Sent: Saturday, August 6, 2022 6:05:51 AM
> > > > To: dev@lucene.apache.org<mailto:dev@lucene.apache.org> <
> > > > dev@lucene.apache.org<mailto:dev@lucene.apache.org>>
> > > > Cc: Lucene Users  > > > java-u...@lucene.apache.org>>; java-dev  > > > <mailto:java-...@lucene.apache.org>>
> > > > Subject: Re: [HELP] Link your Apache Lucene Jira and GitHub account
> ids
> > > > before Thursday August 4 midnight (in your local time)
> > > >
> > > > Hi Adam, I added your linked accounts he

Re: [HELP] Link your Apache Lucene Jira and GitHub account ids before Thursday August 4 midnight (in your local time)

[Tomoko Uchida]

Hi Glen,
I verified your Jira/GitHub usernames and added a mapping.
https://github.com/apache/lucene-jira-archive/commit/ae78d583b40f5bafa1f8ee09854294732dbf530b

Tomoko


2022年8月7日(日) 3:37 Glen Newton :

> jira: gnewton
> github: gnewton  (github.com/gnewton)
>
> Thanks,
> Glen
>
>
>
> On Sat, 6 Aug 2022 at 14:11, Tomoko Uchida 
> wrote:
>
> > Hi everyone.
> >
> > I wanted to let you know that we'll extend the deadline until the date
> the
> > migration is started (the date is not fixed yet).
> > Please let us know your Jira/Github usernames if you don't see mapping(s)
> > for your account in this file:
> >
> >
> https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified
> >
> > Tomoko
> >
> >
> > 2022年8月7日(日) 1:36 Baris Kazar :
> >
> > > Thank You Thank You
> > > Best regards
> > > 
> > > From: Michael McCandless 
> > > Sent: Saturday, August 6, 2022 11:29:25 AM
> > > To: Baris Kazar 
> > > Cc: java-u...@lucene.apache.org 
> > > Subject: Re: [HELP] Link your Apache Lucene Jira and GitHub account ids
> > > before Thursday August 4 midnight (in your local time)
> > >
> > > OK done:
> > >
> >
> https://github.com/apache/lucene-jira-archive/commit/13fa4cb46a1a6d609448240e4f66c263da8b3fd1
> > > <
> > >
> >
> https://urldefense.com/v3/__https://github.com/apache/lucene-jira-archive/commit/13fa4cb46a1a6d609448240e4f66c263da8b3fd1__;!!ACWV5N9M2RV99hQ!OJffdSKrjdfY7VYGcAVGsx4rKHPICvgac4eOcXOf1fnT7u9fJ2RSu9toYPgowHx72UC33Ixg1s1BLKR6GBFgnw$
> > > >
> > >
> > > Mike McCandless
> > >
> > > http://blog.mikemccandless.com<
> > >
> >
> https://urldefense.com/v3/__http://blog.mikemccandless.com__;!!ACWV5N9M2RV99hQ!OJffdSKrjdfY7VYGcAVGsx4rKHPICvgac4eOcXOf1fnT7u9fJ2RSu9toYPgowHx72UC33Ixg1s1BLKQULWvYcw$
> > > >
> > >
> > >
> > > On Sat, Aug 6, 2022 at 10:29 AM Baris Kazar  > > <mailto:baris.ka...@oracle.com>> wrote:
> > > I think so.
> > > Best regards
> > > 
> > > From: Michael McCandless  > > luc...@mikemccandless.com>>
> > > Sent: Saturday, August 6, 2022 10:12 AM
> > > To: java-u...@lucene.apache.org<mailto:java-u...@lucene.apache.org> <
> > > java-u...@lucene.apache.org<mailto:java-u...@lucene.apache.org>>
> > > Cc: Baris Kazar mailto:baris.ka...@oracle.com
> >>
> > > Subject: Re: [HELP] Link your Apache Lucene Jira and GitHub account ids
> > > before Thursday August 4 midnight (in your local time)
> > >
> > > Thanks Baris,
> > >
> > > And your Jira ID is bkazar right?
> > >
> > > Mike
> > >
> > > On Sat, Aug 6, 2022 at 10:05 AM Baris Kazar  > > <mailto:baris.ka...@oracle.com>> wrote:
> > > My github username is bmkazar
> > > can You please register me?
> > > Best regards
> > > 
> > > From: Michael McCandless  > > luc...@mikemccandless.com>>
> > > Sent: Saturday, August 6, 2022 6:05:51 AM
> > > To: dev@lucene.apache.org<mailto:dev@lucene.apache.org> <
> > > dev@lucene.apache.org<mailto:dev@lucene.apache.org>>
> > > Cc: Lucene Users  > > java-u...@lucene.apache.org>>; java-dev  > > <mailto:java-...@lucene.apache.org>>
> > > Subject: Re: [HELP] Link your Apache Lucene Jira and GitHub account ids
> > > before Thursday August 4 midnight (in your local time)
> > >
> > > Hi Adam, I added your linked accounts here:
> > >
> > >
> >
> https://urldefense.com/v3/__https://github.com/apache/lucene-jira-archive/commit/c228cb184c073f4b96cd68d45a000cf390455b7c__;!!ACWV5N9M2RV99hQ!KNwyR7RuqeuKpyzEemagEZzGRGtdqjpE-OWaDfjjyZVHJ-zgsGLyYJhZ7ZWJCI1NrWR6H4DYdMbB8nLk1DO04g$
> > >
> > > And Tomoko added Rushabh's linked accounts here:
> > >
> > >
> > >
> >
> https://urldefense.com/v3/__https://github.com/apache/lucene-jira-archive/commit/6f9501ec68792c1b287e93770f7a9dfd351b86fb__;!!ACWV5N9M2RV99hQ!KNwyR7RuqeuKpyzEemagEZzGRGtdqjpE-OWaDfjjyZVHJ-zgsGLyYJhZ7ZWJCI1NrWR6H4DYdMbB8nITwUFX0A$
> > >
> > > Keep the linked accounts coming!
> > >
> > > Mike
> > >
> > > On Thu, Aug 4, 2022 at 7:02 PM Rushabh Shah
> > > mailto:rushabh.s...@salesforce.com
> > >.invalid>
> > &g

Re: [HELP] Link your Apache Lucene Jira and GitHub account ids before Thursday August 4 midnight (in your local time)

[Tomoko Uchida]

Hi everyone.

I wanted to let you know that we'll extend the deadline until the date the
migration is started (the date is not fixed yet).
Please let us know your Jira/Github usernames if you don't see mapping(s)
for your account in this file:
https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified

Tomoko


2022年8月7日(日) 1:36 Baris Kazar :

> Thank You Thank You
> Best regards
> 
> From: Michael McCandless 
> Sent: Saturday, August 6, 2022 11:29:25 AM
> To: Baris Kazar 
> Cc: java-u...@lucene.apache.org 
> Subject: Re: [HELP] Link your Apache Lucene Jira and GitHub account ids
> before Thursday August 4 midnight (in your local time)
>
> OK done:
> https://github.com/apache/lucene-jira-archive/commit/13fa4cb46a1a6d609448240e4f66c263da8b3fd1
> <
> https://urldefense.com/v3/__https://github.com/apache/lucene-jira-archive/commit/13fa4cb46a1a6d609448240e4f66c263da8b3fd1__;!!ACWV5N9M2RV99hQ!OJffdSKrjdfY7VYGcAVGsx4rKHPICvgac4eOcXOf1fnT7u9fJ2RSu9toYPgowHx72UC33Ixg1s1BLKR6GBFgnw$
> >
>
> Mike McCandless
>
> http://blog.mikemccandless.com<
> https://urldefense.com/v3/__http://blog.mikemccandless.com__;!!ACWV5N9M2RV99hQ!OJffdSKrjdfY7VYGcAVGsx4rKHPICvgac4eOcXOf1fnT7u9fJ2RSu9toYPgowHx72UC33Ixg1s1BLKQULWvYcw$
> >
>
>
> On Sat, Aug 6, 2022 at 10:29 AM Baris Kazar  > wrote:
> I think so.
> Best regards
> 
> From: Michael McCandless  luc...@mikemccandless.com>>
> Sent: Saturday, August 6, 2022 10:12 AM
> To: java-u...@lucene.apache.org <
> java-u...@lucene.apache.org>
> Cc: Baris Kazar mailto:baris.ka...@oracle.com>>
> Subject: Re: [HELP] Link your Apache Lucene Jira and GitHub account ids
> before Thursday August 4 midnight (in your local time)
>
> Thanks Baris,
>
> And your Jira ID is bkazar right?
>
> Mike
>
> On Sat, Aug 6, 2022 at 10:05 AM Baris Kazar  > wrote:
> My github username is bmkazar
> can You please register me?
> Best regards
> 
> From: Michael McCandless  luc...@mikemccandless.com>>
> Sent: Saturday, August 6, 2022 6:05:51 AM
> To: dev@lucene.apache.org <
> dev@lucene.apache.org>
> Cc: Lucene Users  java-u...@lucene.apache.org>>; java-dev  >
> Subject: Re: [HELP] Link your Apache Lucene Jira and GitHub account ids
> before Thursday August 4 midnight (in your local time)
>
> Hi Adam, I added your linked accounts here:
>
> https://urldefense.com/v3/__https://github.com/apache/lucene-jira-archive/commit/c228cb184c073f4b96cd68d45a000cf390455b7c__;!!ACWV5N9M2RV99hQ!KNwyR7RuqeuKpyzEemagEZzGRGtdqjpE-OWaDfjjyZVHJ-zgsGLyYJhZ7ZWJCI1NrWR6H4DYdMbB8nLk1DO04g$
>
> And Tomoko added Rushabh's linked accounts here:
>
>
> https://urldefense.com/v3/__https://github.com/apache/lucene-jira-archive/commit/6f9501ec68792c1b287e93770f7a9dfd351b86fb__;!!ACWV5N9M2RV99hQ!KNwyR7RuqeuKpyzEemagEZzGRGtdqjpE-OWaDfjjyZVHJ-zgsGLyYJhZ7ZWJCI1NrWR6H4DYdMbB8nITwUFX0A$
>
> Keep the linked accounts coming!
>
> Mike
>
> On Thu, Aug 4, 2022 at 7:02 PM Rushabh Shah
> mailto:rushabh.s...@salesforce.com>.invalid>
> wrote:
>
> > Hi,
> > My mapping is:
> > JiraName,GitHubAccount,JiraDispName
> > shahrs87, shahrs87, Rushabh Shah
> >
> > Thank you Tomoko and Mike for all of your hard work.
> >
> >
> >
> >
> > On Sun, Jul 31, 2022 at 3:08 AM Michael McCandless <
> > luc...@mikemccandless.com> wrote:
> >
> >> Hello Lucene users, contributors and developers,
> >>
> >> If you have used Lucene's Jira and you have a GitHub account as well,
> >> please check whether your user id mapping is in this file:
> >>
> https://urldefense.com/v3/__https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified__;!!ACWV5N9M2RV99hQ!KNwyR7RuqeuKpyzEemagEZzGRGtdqjpE-OWaDfjjyZVHJ-zgsGLyYJhZ7ZWJCI1NrWR6H4DYdMbB8nLjA_KarQ$
> >>
> >> If not, please reply to this email and we will try to add you.
> >>
> >> Please forward this email to anyone you know might be impacted and who
> >> might not be tracking the Lucene lists.
> >>
> >>
> >> Full details:
> >>
> >> The Lucene project will soon migrate from Jira to GitHub for issue
> >> tracking.
> >>
> >> There have been discussions, votes, a migration tool created / iterated
> >> (thanks to Tomoko Uchida's incredibly hard work), all iterating on
> Lucene's
> >> dev list.
> >>
> >> When we run the migration, we would like to map Jira users to the right
> >> GitHub users to properly @-mention the right person and make it easier
> for
> >> you to find issues you have engaged with.
> >>
> >> Mike McCandless
> >>
> >>
> 

***UNCHECKED*** Re: [HELP] Link your Apache Lucene Jira and GitHub account ids before Thursday August 4 midnight (in your local time)

[Tomoko Uchida]

Hi Rushabh.

Thanks, I added a mapping for your accounts:
https://github.com/apache/lucene-jira-archive/commit/6f9501ec68792c1b287e93770f7a9dfd351b86fb

Tomoko


2022年8月5日(金) 8:02 Rushabh Shah :

> Hi,
> My mapping is:
> JiraName,GitHubAccount,JiraDispName
> shahrs87, shahrs87, Rushabh Shah
>
> Thank you Tomoko and Mike for all of your hard work.
>
>
>
>
> On Sun, Jul 31, 2022 at 3:08 AM Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> Hello Lucene users, contributors and developers,
>>
>> If you have used Lucene's Jira and you have a GitHub account as well,
>> please check whether your user id mapping is in this file:
>> https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified
>>
>> If not, please reply to this email and we will try to add you.
>>
>> Please forward this email to anyone you know might be impacted and who
>> might not be tracking the Lucene lists.
>>
>>
>> Full details:
>>
>> The Lucene project will soon migrate from Jira to GitHub for issue
>> tracking.
>>
>> There have been discussions, votes, a migration tool created / iterated
>> (thanks to Tomoko Uchida's incredibly hard work), all iterating on Lucene's
>> dev list.
>>
>> When we run the migration, we would like to map Jira users to the right
>> GitHub users to properly @-mention the right person and make it easier for
>> you to find issues you have engaged with.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>

Re: [HELP] Link your Apache Lucene Jira and GitHub account ids before Thursday August 4 midnight (in your local time)

[Tomoko Uchida]

Hi Atri and Christian,
thanks for your reply, we already have your accounts in

-
https://github.com/apache/lucene-jira-archive/blob/7654c0168a86fb05e942666d4514d48966d223bb/migration/mappings-data/account-map.csv.20220722.verified#L42
-
https://github.com/apache/lucene-jira-archive/blob/7654c0168a86fb05e942666d4514d48966d223bb/migration/mappings-data/account-map.csv.20220722.verified#L47
-
https://github.com/apache/lucene-jira-archive/blob/7654c0168a86fb05e942666d4514d48966d223bb/migration/mappings-data/account-map.csv.20220722.verified#L348

Just to clarify Mike's intention a bit, we have already completed account
mappings for almost all committers (except for a few people listed here
 - any
information is welcome).
For committers, we have various information to programmatically or manually
collect and verify their corresponding GitHub accounts.

But for **external contributors who haven't sent PRs to Lucene yet**, we
have few clues to associate their Jira and GitHub accounts.
If you have reported issues or joined discussions in Lucene Jira, please
check if your account is in this list
https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified
.
If not, please reply to this email or make a PR to the file. We'll add your
account(s) there.

Tomoko


2022年8月1日(月) 20:13 Christian Moen :

> Thanks.  My mapping is:
>
> cm,cmoen,Christian Moen
>
>
> On Sun, Jul 31, 2022 at 12:08 PM Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> Hello Lucene users, contributors and developers,
>>
>> If you have used Lucene's Jira and you have a GitHub account as well,
>> please check whether your user id mapping is in this file:
>> https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified
>>
>> If not, please reply to this email and we will try to add you.
>>
>> Please forward this email to anyone you know might be impacted and who
>> might not be tracking the Lucene lists.
>>
>>
>> Full details:
>>
>> The Lucene project will soon migrate from Jira to GitHub for issue
>> tracking.
>>
>> There have been discussions, votes, a migration tool created / iterated
>> (thanks to Tomoko Uchida's incredibly hard work), all iterating on Lucene's
>> dev list.
>>
>> When we run the migration, we would like to map Jira users to the right
>> GitHub users to properly @-mention the right person and make it easier for
>> you to find issues you have engaged with.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>

Re: [HELP] Link your Apache Lucene Jira and GitHub account ids before Thursday August 4 midnight (in your local time)

[Tomoko Uchida]

Hi Mike, Marcus, and Praveen:

I verified the added two mappings - these Jira users have activity on
Lucene Jira, also corresponding GitHub accounts are valid.
- marcussorealheis
- pru30

Tomoko


2022年8月1日(月) 18:40 Michael McCandless :

> Thanks Praveen,
>
> I added your mapping here:
> https://github.com/apache/lucene-jira-archive/commit/765fec2a19063e97c3d3de0a3528c16ba602b0bf
>
> Please verify!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Mon, Aug 1, 2022 at 4:48 AM Praveen Nishchal 
> wrote:
>
>> Hi Mike,
>>
>> Please find details
>>
>> JiraName,GitHubAccount,JiraDispName
>> pru30,https://github.com/praveennish,Praveen Nishchal
>>
>>
>> On Sun, Jul 31, 2022 at 3:38 PM Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>> Hello Lucene users, contributors and developers,
>>>
>>> If you have used Lucene's Jira and you have a GitHub account as well,
>>> please check whether your user id mapping is in this file:
>>> https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified
>>>
>>> If not, please reply to this email and we will try to add you.
>>>
>>> Please forward this email to anyone you know might be impacted and who
>>> might not be tracking the Lucene lists.
>>>
>>>
>>> Full details:
>>>
>>> The Lucene project will soon migrate from Jira to GitHub for issue
>>> tracking.
>>>
>>> There have been discussions, votes, a migration tool created / iterated
>>> (thanks to Tomoko Uchida's incredibly hard work), all iterating on Lucene's
>>> dev list.
>>>
>>> When we run the migration, we would like to map Jira users to the right
>>> GitHub users to properly @-mention the right person and make it easier for
>>> you to find issues you have engaged with.
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>

Re: [HELP] Please spot-check the migrated Lucene GitHub issues!

[Tomoko Uchida]

> Is it intentional that we do not set Assignees on migration?

You can assign a GitHub account only when it has push access to the
repository; it was infeasible to give push access to all committers to the
test repo (an invite/accept flow is needed for each committer).
Assignees will be set when the actual migration on apache/lucene repo -
every assignee in Jira should have push access to it.

Tomoko


2022年7月31日(日) 8:16 Michael McCandless :

> Is it intentional that we do not set Assignees on migration?
>
> E.g. this issue (
> https://github.com/mocobeta/forks-migration-test/issues/5916) is assigned
> to Ryan in Jira, but has no Assignees in GitHub issue.
>
> Mike
>
> On Sat, Jul 30, 2022 at 6:40 PM Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> On Sat, Jul 30, 2022 at 6:29 PM Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>> How about hidden (secure) issues?  I assume they did not migrate as
>>> well?  Do GitHub issues offer such hidden/secure issues?
>>>
>>
>> OK nevermind -- Tomoko already raised this question here on June 15 and
>> the conclusion was that Lucene never enabled such private issues (Solr
>> did), so there is nothing to do/see here!
>>
>> Mike
>> --
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
> --
> Mike McCandless
>
> http://blog.mikemccandless.com
>

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Tomoko Uchida]

Just an update on the migration procedure.

> 2. Send a message to dev@ stating new issues should now be opened in
github
> 3. Start the migration
> I think the difference with this and what was previously described on
this thread is there would be no downtime for new issues.
I confirmed it's safe to create new issues while the migration is in
progress, so there will be no downtime for new issues.

For existing issues, I don't think it'd be practical to suspend our issue
system for two or three days, I would migrate comments on existing issues
created during migration in Jira by my GitHub account. A bit awkward, but
it'd be an acceptable workaround I think.

Tomoko


2022年7月19日(火) 23:24 Tomoko Uchida :

> > I think missing a few updates would be preferable to having 10k
> messages. Just my opinion though.
> I don't have objections. Then let's disable Jira notification on issues@
> before the script is started - maybe, issue watchers will notice that if
> there are comments from someone.
> Other opinions?
>
> 2022年7月19日(火) 23:17 Houston Putman :
>
>> I think missing a few updates would be preferable to having 10k messages.
>> Just my opinion though.
>>
>> On Tue, Jul 19, 2022 at 10:11 AM Tomoko Uchida <
>> tomoko.uchida.1...@gmail.com> wrote:
>>
>>> > 1. Make Jira read only
>>>>
>>>> At the very last step, we'll add comments saying "This was moved GitHub
>>>> " to each Jira issue. It has to be done after the migration was
>>>> completed.
>>>>
>>>
>>> > Is this going to send 10k emails to the mailing list? I’ll need to
>>> update my filters so that these skip my inbox in that case.
>>>
>>> Yes, I will let you all know the mail template before starting the
>>> migration.
>>> Or, a Jira project admin could completely disable notifications from
>>> Jira - but this could bury real notifications (issues/comments by humans
>>> who don't recognize the migration).
>>>
>>> 2022年7月19日(火) 23:05 Tomoko Uchida :
>>>
>>>> > 2. Send a message to dev@ stating new issues should now be opened in
>>>> github
>>>> > 3. Start the migration
>>>>
>>>> Maybe we can do a simulation for this.
>>>> I plan a rehearsal that migrates whole existing issues into a test repo
>>>> next week. Could some people help/test it (randomly open/close issues, add
>>>> comments, etc. while the migration script is running)?
>>>>
>>>>
>>>> 2022年7月19日(火) 22:47 Tomoko Uchida :
>>>>
>>>>> > 1. Make Jira read only
>>>>>
>>>>> At the very last step, we'll add comments saying "This was moved
>>>>> GitHub " to each Jira issue. It has to be done after the migration 
>>>>> was
>>>>> completed.
>>>>>
>>>>> > 2. Send a message to dev@ stating new issues should now be opened
>>>>> in github
>>>>> > 3. Start the migration
>>>>>
>>>>> In theory, it would be okay to me. I just wanted to avoid any risks
>>>>> during migration. Let me give time to consider/check if the migration can
>>>>> be safely done while new issues are created (by humans).
>>>>>
>>>>>
>>>>> 2022年7月19日(火) 21:56 Ryan Ernst :
>>>>>
>>>>>> > Yes, it won't be a really atomic switch
>>>>>>
>>>>>> While it may not be completely atomic, could it be closer? GitHub
>>>>>> already supports new issues, developers are just advised against opening
>>>>>> there. Could the order of events be:
>>>>>>
>>>>>> 1. Make Jira read only
>>>>>> 2. Send a message to dev@ stating new issues should now be opened in
>>>>>> github
>>>>>> 3. Start the migration
>>>>>> 4. When the migration is complete, send another message notifying
>>>>>> devs that pre-existing Jiras are now in GitHub,so they can then be
>>>>>> commented on and edited there.
>>>>>>
>>>>>> I think the difference with this and what was previously described on
>>>>>> this thread is there would be no downtime for new issues.
>>>>>>
>>>>>> On Tue, Jul 19, 2022 at 00:07 Tomoko Uchida <
>>>>>> tomoko.uchida.1...@gmail.com> wrote:
>>>>>>
>>>>>>> OK, thank you everyone for your 

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Tomoko Uchida]

> I think missing a few updates would be preferable to having 10k messages.
Just my opinion though.
I don't have objections. Then let's disable Jira notification on issues@
before the script is started - maybe, issue watchers will notice that if
there are comments from someone.
Other opinions?

2022年7月19日(火) 23:17 Houston Putman :

> I think missing a few updates would be preferable to having 10k messages.
> Just my opinion though.
>
> On Tue, Jul 19, 2022 at 10:11 AM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
>> > 1. Make Jira read only
>>>
>>> At the very last step, we'll add comments saying "This was moved GitHub
>>> " to each Jira issue. It has to be done after the migration was
>>> completed.
>>>
>>
>> > Is this going to send 10k emails to the mailing list? I’ll need to
>> update my filters so that these skip my inbox in that case.
>>
>> Yes, I will let you all know the mail template before starting the
>> migration.
>> Or, a Jira project admin could completely disable notifications from Jira
>> - but this could bury real notifications (issues/comments by humans who
>> don't recognize the migration).
>>
>> 2022年7月19日(火) 23:05 Tomoko Uchida :
>>
>>> > 2. Send a message to dev@ stating new issues should now be opened in
>>> github
>>> > 3. Start the migration
>>>
>>> Maybe we can do a simulation for this.
>>> I plan a rehearsal that migrates whole existing issues into a test repo
>>> next week. Could some people help/test it (randomly open/close issues, add
>>> comments, etc. while the migration script is running)?
>>>
>>>
>>> 2022年7月19日(火) 22:47 Tomoko Uchida :
>>>
>>>> > 1. Make Jira read only
>>>>
>>>> At the very last step, we'll add comments saying "This was moved GitHub
>>>> " to each Jira issue. It has to be done after the migration was
>>>> completed.
>>>>
>>>> > 2. Send a message to dev@ stating new issues should now be opened in
>>>> github
>>>> > 3. Start the migration
>>>>
>>>> In theory, it would be okay to me. I just wanted to avoid any risks
>>>> during migration. Let me give time to consider/check if the migration can
>>>> be safely done while new issues are created (by humans).
>>>>
>>>>
>>>> 2022年7月19日(火) 21:56 Ryan Ernst :
>>>>
>>>>> > Yes, it won't be a really atomic switch
>>>>>
>>>>> While it may not be completely atomic, could it be closer? GitHub
>>>>> already supports new issues, developers are just advised against opening
>>>>> there. Could the order of events be:
>>>>>
>>>>> 1. Make Jira read only
>>>>> 2. Send a message to dev@ stating new issues should now be opened in
>>>>> github
>>>>> 3. Start the migration
>>>>> 4. When the migration is complete, send another message notifying devs
>>>>> that pre-existing Jiras are now in GitHub,so they can then be commented on
>>>>> and edited there.
>>>>>
>>>>> I think the difference with this and what was previously described on
>>>>> this thread is there would be no downtime for new issues.
>>>>>
>>>>> On Tue, Jul 19, 2022 at 00:07 Tomoko Uchida <
>>>>> tomoko.uchida.1...@gmail.com> wrote:
>>>>>
>>>>>> OK, thank you everyone for your comments/suggestions.
>>>>>> I will ask infra to make Lucene Jira read-only after the migration is
>>>>>> completed (if there are no explicit objections). For people who are
>>>>>> critically affected by this change, please let me know about your
>>>>>> inconvenience. I'll try to find acceptable solutions.
>>>>>>
>>>>>> > I would prefer that we make a nearly atomic switch -- up until time
>>>>>> X we use Jira, then it goes read-only and at time X + t (t being how long
>>>>>> the migration takes, likely a day or two?), GitHub issues opens for
>>>>>> business.
>>>>>>
>>>>>> Yes, it won't be a really atomic switch - there will be a moratorium
>>>>>> in our issue system (where GitHub issue is not lifted yet, but a Jira
>>>>>> snapshot is already taken). I estimate the whole migration process will
>>>>>> take at least three days

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Tomoko Uchida]

>
I plan a rehearsal that migrates whole existing issues into a test repo
next week. Could some people help/test it (randomly open/close issues, add
comments, etc. while the migration script is running)?

It'd be done by an agent program - I'll draft it.


2022年7月19日(火) 23:10 Tomoko Uchida :

> > 1. Make Jira read only
>>
>> At the very last step, we'll add comments saying "This was moved GitHub
>> " to each Jira issue. It has to be done after the migration was
>> completed.
>>
>
> > Is this going to send 10k emails to the mailing list? I’ll need to
> update my filters so that these skip my inbox in that case.
>
> Yes, I will let you all know the mail template before starting the
> migration.
> Or, a Jira project admin could completely disable notifications from Jira
> - but this could bury real notifications (issues/comments by humans who
> don't recognize the migration).
>
> 2022年7月19日(火) 23:05 Tomoko Uchida :
>
>> > 2. Send a message to dev@ stating new issues should now be opened in
>> github
>> > 3. Start the migration
>>
>> Maybe we can do a simulation for this.
>> I plan a rehearsal that migrates whole existing issues into a test repo
>> next week. Could some people help/test it (randomly open/close issues, add
>> comments, etc. while the migration script is running)?
>>
>>
>> 2022年7月19日(火) 22:47 Tomoko Uchida :
>>
>>> > 1. Make Jira read only
>>>
>>> At the very last step, we'll add comments saying "This was moved GitHub
>>> " to each Jira issue. It has to be done after the migration was
>>> completed.
>>>
>>> > 2. Send a message to dev@ stating new issues should now be opened in
>>> github
>>> > 3. Start the migration
>>>
>>> In theory, it would be okay to me. I just wanted to avoid any risks
>>> during migration. Let me give time to consider/check if the migration can
>>> be safely done while new issues are created (by humans).
>>>
>>>
>>> 2022年7月19日(火) 21:56 Ryan Ernst :
>>>
>>>> > Yes, it won't be a really atomic switch
>>>>
>>>> While it may not be completely atomic, could it be closer? GitHub
>>>> already supports new issues, developers are just advised against opening
>>>> there. Could the order of events be:
>>>>
>>>> 1. Make Jira read only
>>>> 2. Send a message to dev@ stating new issues should now be opened in
>>>> github
>>>> 3. Start the migration
>>>> 4. When the migration is complete, send another message notifying devs
>>>> that pre-existing Jiras are now in GitHub,so they can then be commented on
>>>> and edited there.
>>>>
>>>> I think the difference with this and what was previously described on
>>>> this thread is there would be no downtime for new issues.
>>>>
>>>> On Tue, Jul 19, 2022 at 00:07 Tomoko Uchida <
>>>> tomoko.uchida.1...@gmail.com> wrote:
>>>>
>>>>> OK, thank you everyone for your comments/suggestions.
>>>>> I will ask infra to make Lucene Jira read-only after the migration is
>>>>> completed (if there are no explicit objections). For people who are
>>>>> critically affected by this change, please let me know about your
>>>>> inconvenience. I'll try to find acceptable solutions.
>>>>>
>>>>> > I would prefer that we make a nearly atomic switch -- up until time
>>>>> X we use Jira, then it goes read-only and at time X + t (t being how long
>>>>> the migration takes, likely a day or two?), GitHub issues opens for
>>>>> business.
>>>>>
>>>>> Yes, it won't be a really atomic switch - there will be a moratorium
>>>>> in our issue system (where GitHub issue is not lifted yet, but a Jira
>>>>> snapshot is already taken). I estimate the whole migration process will
>>>>> take at least three days; will make a mail thread about the detailed
>>>>> schedule.
>>>>>
>>>>> Tomoko
>>>>>
>>>>>
>>>>> 2022年7月19日(火) 2:38 Gus Heck :
>>>>>
>>>>>> I am 100% for preventing creation of new issues in Jira, new issues
>>>>>> should only be created in one system at any one time. I feel that 
>>>>>> existing
>>>>>> issues should be completed in their original system for continuity, and
>>>>>> anticipate

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Tomoko Uchida]

>
> > 1. Make Jira read only
>
> At the very last step, we'll add comments saying "This was moved GitHub
> " to each Jira issue. It has to be done after the migration was
> completed.
>

> Is this going to send 10k emails to the mailing list? I’ll need to update
my filters so that these skip my inbox in that case.

Yes, I will let you all know the mail template before starting the
migration.
Or, a Jira project admin could completely disable notifications from Jira -
but this could bury real notifications (issues/comments by humans who don't
recognize the migration).

2022年7月19日(火) 23:05 Tomoko Uchida :

> > 2. Send a message to dev@ stating new issues should now be opened in
> github
> > 3. Start the migration
>
> Maybe we can do a simulation for this.
> I plan a rehearsal that migrates whole existing issues into a test repo
> next week. Could some people help/test it (randomly open/close issues, add
> comments, etc. while the migration script is running)?
>
>
> 2022年7月19日(火) 22:47 Tomoko Uchida :
>
>> > 1. Make Jira read only
>>
>> At the very last step, we'll add comments saying "This was moved GitHub
>> " to each Jira issue. It has to be done after the migration was
>> completed.
>>
>> > 2. Send a message to dev@ stating new issues should now be opened in
>> github
>> > 3. Start the migration
>>
>> In theory, it would be okay to me. I just wanted to avoid any risks
>> during migration. Let me give time to consider/check if the migration can
>> be safely done while new issues are created (by humans).
>>
>>
>> 2022年7月19日(火) 21:56 Ryan Ernst :
>>
>>> > Yes, it won't be a really atomic switch
>>>
>>> While it may not be completely atomic, could it be closer? GitHub
>>> already supports new issues, developers are just advised against opening
>>> there. Could the order of events be:
>>>
>>> 1. Make Jira read only
>>> 2. Send a message to dev@ stating new issues should now be opened in
>>> github
>>> 3. Start the migration
>>> 4. When the migration is complete, send another message notifying devs
>>> that pre-existing Jiras are now in GitHub,so they can then be commented on
>>> and edited there.
>>>
>>> I think the difference with this and what was previously described on
>>> this thread is there would be no downtime for new issues.
>>>
>>> On Tue, Jul 19, 2022 at 00:07 Tomoko Uchida <
>>> tomoko.uchida.1...@gmail.com> wrote:
>>>
>>>> OK, thank you everyone for your comments/suggestions.
>>>> I will ask infra to make Lucene Jira read-only after the migration is
>>>> completed (if there are no explicit objections). For people who are
>>>> critically affected by this change, please let me know about your
>>>> inconvenience. I'll try to find acceptable solutions.
>>>>
>>>> > I would prefer that we make a nearly atomic switch -- up until time X
>>>> we use Jira, then it goes read-only and at time X + t (t being how long the
>>>> migration takes, likely a day or two?), GitHub issues opens for business.
>>>>
>>>> Yes, it won't be a really atomic switch - there will be a moratorium in
>>>> our issue system (where GitHub issue is not lifted yet, but a Jira snapshot
>>>> is already taken). I estimate the whole migration process will take at
>>>> least three days; will make a mail thread about the detailed schedule.
>>>>
>>>> Tomoko
>>>>
>>>>
>>>> 2022年7月19日(火) 2:38 Gus Heck :
>>>>
>>>>> I am 100% for preventing creation of new issues in Jira, new issues
>>>>> should only be created in one system at any one time. I feel that existing
>>>>> issues should be completed in their original system for continuity, and
>>>>> anticipate that in any case Jira will mean readable in perpetuity. The
>>>>> copying of old issues to github as a convenience for users so they aren't
>>>>> forced to look at 2 places also sounds good. Raising the standard for what
>>>>> we consider a stale issue and closing out things in Jira faster to get to 
>>>>> a
>>>>> one system situation sooner also seems good.
>>>>>
>>>>> Things I think we should strive to avoid:
>>>>> 1) An issue in Jira that is unresolved and duplicated (possibly
>>>>> resolved) in github... possibly leading to someone wasting time repeating 
>>>>>

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Tomoko Uchida]

> 2. Send a message to dev@ stating new issues should now be opened in
github
> 3. Start the migration

Maybe we can do a simulation for this.
I plan a rehearsal that migrates whole existing issues into a test repo
next week. Could some people help/test it (randomly open/close issues, add
comments, etc. while the migration script is running)?


2022年7月19日(火) 22:47 Tomoko Uchida :

> > 1. Make Jira read only
>
> At the very last step, we'll add comments saying "This was moved GitHub
> " to each Jira issue. It has to be done after the migration was
> completed.
>
> > 2. Send a message to dev@ stating new issues should now be opened in
> github
> > 3. Start the migration
>
> In theory, it would be okay to me. I just wanted to avoid any risks during
> migration. Let me give time to consider/check if the migration can be
> safely done while new issues are created (by humans).
>
>
> 2022年7月19日(火) 21:56 Ryan Ernst :
>
>> > Yes, it won't be a really atomic switch
>>
>> While it may not be completely atomic, could it be closer? GitHub already
>> supports new issues, developers are just advised against opening there.
>> Could the order of events be:
>>
>> 1. Make Jira read only
>> 2. Send a message to dev@ stating new issues should now be opened in
>> github
>> 3. Start the migration
>> 4. When the migration is complete, send another message notifying devs
>> that pre-existing Jiras are now in GitHub,so they can then be commented on
>> and edited there.
>>
>> I think the difference with this and what was previously described on
>> this thread is there would be no downtime for new issues.
>>
>> On Tue, Jul 19, 2022 at 00:07 Tomoko Uchida 
>> wrote:
>>
>>> OK, thank you everyone for your comments/suggestions.
>>> I will ask infra to make Lucene Jira read-only after the migration is
>>> completed (if there are no explicit objections). For people who are
>>> critically affected by this change, please let me know about your
>>> inconvenience. I'll try to find acceptable solutions.
>>>
>>> > I would prefer that we make a nearly atomic switch -- up until time X
>>> we use Jira, then it goes read-only and at time X + t (t being how long the
>>> migration takes, likely a day or two?), GitHub issues opens for business.
>>>
>>> Yes, it won't be a really atomic switch - there will be a moratorium in
>>> our issue system (where GitHub issue is not lifted yet, but a Jira snapshot
>>> is already taken). I estimate the whole migration process will take at
>>> least three days; will make a mail thread about the detailed schedule.
>>>
>>> Tomoko
>>>
>>>
>>> 2022年7月19日(火) 2:38 Gus Heck :
>>>
>>>> I am 100% for preventing creation of new issues in Jira, new issues
>>>> should only be created in one system at any one time. I feel that existing
>>>> issues should be completed in their original system for continuity, and
>>>> anticipate that in any case Jira will mean readable in perpetuity. The
>>>> copying of old issues to github as a convenience for users so they aren't
>>>> forced to look at 2 places also sounds good. Raising the standard for what
>>>> we consider a stale issue and closing out things in Jira faster to get to a
>>>> one system situation sooner also seems good.
>>>>
>>>> Things I think we should strive to avoid:
>>>> 1) An issue in Jira that is unresolved and duplicated (possibly
>>>> resolved) in github... possibly leading to someone wasting time repeating a
>>>> solution or giving up thinking there isn't a solution etc.
>>>> 2) Any issues for which the discussion is split across systems and thus
>>>> it would be easy to miss part of the discussion and/or not have the issue
>>>> come up in searches that are relevant to that issue.
>>>>
>>>> Also, a common pattern for me is to throw an issue ticket number that I
>>>> have noted somewhere (i.e LUCENE-12345) into google and browse to the
>>>> ticket if it comes up directly or to a mail archive result which has a link
>>>> to the Jira. This is faster than searching in jira itself because I can
>>>> always get to google in a single keystroke (new tab).  Sadly this is
>>>> unlikely to work with github which does not put a project moniker on the
>>>> issue id. Not sure how many others do this but if it's common I wonder if
>>>> we can auto-insert something of the sort into github tickets so that mail
>

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Tomoko Uchida]

> 1. Make Jira read only

At the very last step, we'll add comments saying "This was moved GitHub
" to each Jira issue. It has to be done after the migration was
completed.

> 2. Send a message to dev@ stating new issues should now be opened in
github
> 3. Start the migration

In theory, it would be okay to me. I just wanted to avoid any risks during
migration. Let me give time to consider/check if the migration can be
safely done while new issues are created (by humans).


2022年7月19日(火) 21:56 Ryan Ernst :

> > Yes, it won't be a really atomic switch
>
> While it may not be completely atomic, could it be closer? GitHub already
> supports new issues, developers are just advised against opening there.
> Could the order of events be:
>
> 1. Make Jira read only
> 2. Send a message to dev@ stating new issues should now be opened in
> github
> 3. Start the migration
> 4. When the migration is complete, send another message notifying devs
> that pre-existing Jiras are now in GitHub,so they can then be commented on
> and edited there.
>
> I think the difference with this and what was previously described on this
> thread is there would be no downtime for new issues.
>
> On Tue, Jul 19, 2022 at 00:07 Tomoko Uchida 
> wrote:
>
>> OK, thank you everyone for your comments/suggestions.
>> I will ask infra to make Lucene Jira read-only after the migration is
>> completed (if there are no explicit objections). For people who are
>> critically affected by this change, please let me know about your
>> inconvenience. I'll try to find acceptable solutions.
>>
>> > I would prefer that we make a nearly atomic switch -- up until time X
>> we use Jira, then it goes read-only and at time X + t (t being how long the
>> migration takes, likely a day or two?), GitHub issues opens for business.
>>
>> Yes, it won't be a really atomic switch - there will be a moratorium in
>> our issue system (where GitHub issue is not lifted yet, but a Jira snapshot
>> is already taken). I estimate the whole migration process will take at
>> least three days; will make a mail thread about the detailed schedule.
>>
>> Tomoko
>>
>>
>> 2022年7月19日(火) 2:38 Gus Heck :
>>
>>> I am 100% for preventing creation of new issues in Jira, new issues
>>> should only be created in one system at any one time. I feel that existing
>>> issues should be completed in their original system for continuity, and
>>> anticipate that in any case Jira will mean readable in perpetuity. The
>>> copying of old issues to github as a convenience for users so they aren't
>>> forced to look at 2 places also sounds good. Raising the standard for what
>>> we consider a stale issue and closing out things in Jira faster to get to a
>>> one system situation sooner also seems good.
>>>
>>> Things I think we should strive to avoid:
>>> 1) An issue in Jira that is unresolved and duplicated (possibly
>>> resolved) in github... possibly leading to someone wasting time repeating a
>>> solution or giving up thinking there isn't a solution etc.
>>> 2) Any issues for which the discussion is split across systems and thus
>>> it would be easy to miss part of the discussion and/or not have the issue
>>> come up in searches that are relevant to that issue.
>>>
>>> Also, a common pattern for me is to throw an issue ticket number that I
>>> have noted somewhere (i.e LUCENE-12345) into google and browse to the
>>> ticket if it comes up directly or to a mail archive result which has a link
>>> to the Jira. This is faster than searching in jira itself because I can
>>> always get to google in a single keystroke (new tab).  Sadly this is
>>> unlikely to work with github which does not put a project moniker on the
>>> issue id. Not sure how many others do this but if it's common I wonder if
>>> we can auto-insert something of the sort into github tickets so that mail
>>> archives from the tickets are similarly searchable? Like LUCENE-G12345 for
>>> github ticket #12345? The two key things that make this useful are the
>>> searchability of the ID in google and the fact that ticket mails often have
>>> a link to the ticket which the archive sites will render as a hyperlink.
>>>
>>> -Gus
>>>
>>> On Mon, Jul 18, 2022 at 11:12 AM David Smiley 
>>> wrote:
>>>
>>>> I suppose someone bent on not using GitHub could also email the patch
>>>> to the dev list, starting a thread around it.
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Dev

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Tomoko Uchida]

OK, thank you everyone for your comments/suggestions.
I will ask infra to make Lucene Jira read-only after the migration is
completed (if there are no explicit objections). For people who are
critically affected by this change, please let me know about your
inconvenience. I'll try to find acceptable solutions.

> I would prefer that we make a nearly atomic switch -- up until time X we
use Jira, then it goes read-only and at time X + t (t being how long the
migration takes, likely a day or two?), GitHub issues opens for business.

Yes, it won't be a really atomic switch - there will be a moratorium in our
issue system (where GitHub issue is not lifted yet, but a Jira snapshot is
already taken). I estimate the whole migration process will take at least
three days; will make a mail thread about the detailed schedule.

Tomoko


2022年7月19日(火) 2:38 Gus Heck :

> I am 100% for preventing creation of new issues in Jira, new issues should
> only be created in one system at any one time. I feel that existing issues
> should be completed in their original system for continuity, and
> anticipate that in any case Jira will mean readable in perpetuity. The
> copying of old issues to github as a convenience for users so they aren't
> forced to look at 2 places also sounds good. Raising the standard for what
> we consider a stale issue and closing out things in Jira faster to get to a
> one system situation sooner also seems good.
>
> Things I think we should strive to avoid:
> 1) An issue in Jira that is unresolved and duplicated (possibly resolved)
> in github... possibly leading to someone wasting time repeating a solution
> or giving up thinking there isn't a solution etc.
> 2) Any issues for which the discussion is split across systems and thus it
> would be easy to miss part of the discussion and/or not have the issue come
> up in searches that are relevant to that issue.
>
> Also, a common pattern for me is to throw an issue ticket number that I
> have noted somewhere (i.e LUCENE-12345) into google and browse to the
> ticket if it comes up directly or to a mail archive result which has a link
> to the Jira. This is faster than searching in jira itself because I can
> always get to google in a single keystroke (new tab).  Sadly this is
> unlikely to work with github which does not put a project moniker on the
> issue id. Not sure how many others do this but if it's common I wonder if
> we can auto-insert something of the sort into github tickets so that mail
> archives from the tickets are similarly searchable? Like LUCENE-G12345 for
> github ticket #12345? The two key things that make this useful are the
> searchability of the ID in google and the fact that ticket mails often have
> a link to the ticket which the archive sites will render as a hyperlink.
>
> -Gus
>
> On Mon, Jul 18, 2022 at 11:12 AM David Smiley  wrote:
>
>> I suppose someone bent on not using GitHub could also email the patch to
>> the dev list, starting a thread around it.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sun, Jul 17, 2022 at 9:14 AM Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>> Hi Team,
>>>
>>> Thanks to Tomoko's amazing hard work (
>>> https://github.com/apache/lucene-jira-archive), we are getting close to
>>> having strong tooling and a solid plan to migrate all past Jira issues to
>>> GItHub issues!
>>>
>>> But one contentious point is whether to leave Jira read-only or
>>> read-write after the migration.  So let's DISCUSS and maybe VOTE to reach
>>> concensus?
>>>
>>> My opinion: I think it'd be crazy to leave Jira read/write.  We would
>>> effectively have two issue trackers.  New users who find Jira through
>>> Google, or through links we have in old blog posts, etc., might
>>> accidentally open new Jira issues or comment on old ones and we may not
>>> even notice.  I think that would harm our community.
>>>
>>> I would prefer that we make a nearly atomic switch -- up until time X we
>>> use Jira, then it goes read-only and at time X + t (t being how long the
>>> migration takes, likely a day or two?), GitHub issues opens for business.
>>> This way we clarly have only one issue tracker at (nearly) all times.  This
>>> would make a clean migration, and reduce risk of trapping users.
>>>
>>> Other opinions?
>>>
>>> Thanks,
>>>
>>> Mike
>>> --
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Tomoko Uchida]

I see. If we forbid people from updating Jira, I hope we will keep dealing
with .patch files (maybe renamed to .patch.txt or -patch.txt) as
before.
I don't want to interfere with the development style of people who prefer
classical/standard patch files over pull requests.

Except for the treatment of .patch files, I don't see any essential
difference between Jira and GitHub issues so far.
For people who don't use GitHub not because of functionality but because of
their policy, I cannot much help. In that case, just blame me - it's a
project I started.


2022年7月18日(月) 19:32 Michael McCandless :

> Indeed, GitHub forbids you from attaching a file with extension .patch!
> Sort of annoying :)
>
> But then one workaround is to rename it to -patch.txt or so.  Of
> course, GitHub won't do pretty rendering of the .patch syntax, but then I
> don't think Jira does either?  It's just an attachment that you must
> download and apply to your local git clone.
>
> GitHub does support mapping a PR to a patch or diff file -- you just
> download the full path to the PR, but add .diff or .patch extension.  E.g.
> https://github.com/apache/lucene-jira-archive/pull/49.patch or
> https://github.com/apache/lucene-jira-archive/pull/49.diff.
>
> The .diff is a straight diff (like "git diff") of all the cumulative
> changes/commits in the PR, while the .patch shows a concatenation of the
> individual commits.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Mon, Jul 18, 2022 at 12:41 AM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
>> I agree that "discussion" will be done on mailing lists (as always).
>> Properly speaking, stopping using Jira means "we don't accept patch style
>> contributions anymore".
>> GitHub doesn't allow ".patch" files as attachments; it'd be reasonable
>> for GitHub.
>>
>> https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/attaching-files
>>
>> I'm not sure if it has a substantial effect and I myself am fine with
>> that - just wanted to clarify what we are going to discard.
>>
>> Tomoko
>>
>>
>> 2022年7月17日(日) 23:40 Michael Sokolov :
>>
>>> I think we'd still have the mailing lists open for discussion. So anyone
>>> not willing or able to use GitHub would still be able to participate in a
>>> meaningful way. Having two parallel bug trackers seems much less useful to
>>> me. I'd rather have people emailing to a list that is active rather than
>>> posting comments to a repository that we may very likely start to ignore.
>>>
>>> On Sun, Jul 17, 2022, 10:09 AM Tomoko Uchida <
>>> tomoko.uchida.1...@gmail.com> wrote:
>>>
>>>> Thank you Mike for opening the discussion.
>>>>
>>>> I don't really have a clear "opinion" on that, but I just wanted to try
>>>> to explain my perspective.
>>>>
>>>> Today almost all development is already going on GitHub pull requests,
>>>> then it would be a natural direction for the majority of devs to move our
>>>> primary conversation platform to GitHub. I think we should try to optimize
>>>> our environment for majorities, although I know we will never be able to
>>>> reach a unanimous agreement.
>>>> Meanwhile, it was not my intention to completely discontinue the
>>>> contribution path via Jira. I rather optimistically thought we could leave
>>>> room for developers who don't use GitHub for any reason.
>>>>
>>>> As for preventing someone from "accidentally" opening Jira issues, we
>>>> could show a text that says "Jira has been deprecated. Please open GitHub
>>>> issue unless you are not able to do so." when he/she is attempting to open
>>>> Jira.
>>>>
>>>> https://confluence.atlassian.com/adminjiraserver/configuring-contexts-and-default-values-for-the-description-field-1047552727.html
>>>>
>>>> I agree that it'd be the cleanest way to make Jira read-only and I
>>>> myself am fine with the proposal - maybe I'm overthinking.
>>>>
>>>> Tomoko
>>>>
>>>>
>>>> 2022年7月17日(日) 22:13 Michael McCandless :
>>>>
>>>>> Hi Team,
>>>>>
>>>>> Thanks to Tomoko's amazing hard work (
>>>>> https://github.com/apache/lucene-jira-archive), we are getting close
>>>>> to having strong tooling and a solid plan to migrate all past Jira issues
>>>>> to GItHub issues!
&g

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Tomoko Uchida]

I agree that "discussion" will be done on mailing lists (as always).
Properly speaking, stopping using Jira means "we don't accept patch style
contributions anymore".
GitHub doesn't allow ".patch" files as attachments; it'd be reasonable for
GitHub.
https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/attaching-files

I'm not sure if it has a substantial effect and I myself am fine with that
- just wanted to clarify what we are going to discard.

Tomoko


2022年7月17日(日) 23:40 Michael Sokolov :

> I think we'd still have the mailing lists open for discussion. So anyone
> not willing or able to use GitHub would still be able to participate in a
> meaningful way. Having two parallel bug trackers seems much less useful to
> me. I'd rather have people emailing to a list that is active rather than
> posting comments to a repository that we may very likely start to ignore.
>
> On Sun, Jul 17, 2022, 10:09 AM Tomoko Uchida 
> wrote:
>
>> Thank you Mike for opening the discussion.
>>
>> I don't really have a clear "opinion" on that, but I just wanted to try
>> to explain my perspective.
>>
>> Today almost all development is already going on GitHub pull requests,
>> then it would be a natural direction for the majority of devs to move our
>> primary conversation platform to GitHub. I think we should try to optimize
>> our environment for majorities, although I know we will never be able to
>> reach a unanimous agreement.
>> Meanwhile, it was not my intention to completely discontinue the
>> contribution path via Jira. I rather optimistically thought we could leave
>> room for developers who don't use GitHub for any reason.
>>
>> As for preventing someone from "accidentally" opening Jira issues, we
>> could show a text that says "Jira has been deprecated. Please open GitHub
>> issue unless you are not able to do so." when he/she is attempting to open
>> Jira.
>>
>> https://confluence.atlassian.com/adminjiraserver/configuring-contexts-and-default-values-for-the-description-field-1047552727.html
>>
>> I agree that it'd be the cleanest way to make Jira read-only and I myself
>> am fine with the proposal - maybe I'm overthinking.
>>
>> Tomoko
>>
>>
>> 2022年7月17日(日) 22:13 Michael McCandless :
>>
>>> Hi Team,
>>>
>>> Thanks to Tomoko's amazing hard work (
>>> https://github.com/apache/lucene-jira-archive), we are getting close to
>>> having strong tooling and a solid plan to migrate all past Jira issues to
>>> GItHub issues!
>>>
>>> But one contentious point is whether to leave Jira read-only or
>>> read-write after the migration.  So let's DISCUSS and maybe VOTE to reach
>>> concensus?
>>>
>>> My opinion: I think it'd be crazy to leave Jira read/write.  We would
>>> effectively have two issue trackers.  New users who find Jira through
>>> Google, or through links we have in old blog posts, etc., might
>>> accidentally open new Jira issues or comment on old ones and we may not
>>> even notice.  I think that would harm our community.
>>>
>>> I would prefer that we make a nearly atomic switch -- up until time X we
>>> use Jira, then it goes read-only and at time X + t (t being how long the
>>> migration takes, likely a day or two?), GitHub issues opens for business.
>>> This way we clarly have only one issue tracker at (nearly) all times.  This
>>> would make a clean migration, and reduce risk of trapping users.
>>>
>>> Other opinions?
>>>
>>> Thanks,
>>>
>>> Mike
>>> --
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Tomoko Uchida]

Thank you Mike for opening the discussion.

I don't really have a clear "opinion" on that, but I just wanted to try to
explain my perspective.

Today almost all development is already going on GitHub pull requests, then
it would be a natural direction for the majority of devs to move our
primary conversation platform to GitHub. I think we should try to optimize
our environment for majorities, although I know we will never be able to
reach a unanimous agreement.
Meanwhile, it was not my intention to completely discontinue the
contribution path via Jira. I rather optimistically thought we could leave
room for developers who don't use GitHub for any reason.

As for preventing someone from "accidentally" opening Jira issues, we could
show a text that says "Jira has been deprecated. Please open GitHub issue
unless you are not able to do so." when he/she is attempting to open Jira.
https://confluence.atlassian.com/adminjiraserver/configuring-contexts-and-default-values-for-the-description-field-1047552727.html

I agree that it'd be the cleanest way to make Jira read-only and I myself
am fine with the proposal - maybe I'm overthinking.

Tomoko


2022年7月17日(日) 22:13 Michael McCandless :

> Hi Team,
>
> Thanks to Tomoko's amazing hard work (
> https://github.com/apache/lucene-jira-archive), we are getting close to
> having strong tooling and a solid plan to migrate all past Jira issues to
> GItHub issues!
>
> But one contentious point is whether to leave Jira read-only or read-write
> after the migration.  So let's DISCUSS and maybe VOTE to reach concensus?
>
> My opinion: I think it'd be crazy to leave Jira read/write.  We would
> effectively have two issue trackers.  New users who find Jira through
> Google, or through links we have in old blog posts, etc., might
> accidentally open new Jira issues or comment on old ones and we may not
> even notice.  I think that would harm our community.
>
> I would prefer that we make a nearly atomic switch -- up until time X we
> use Jira, then it goes read-only and at time X + t (t being how long the
> migration takes, likely a day or two?), GitHub issues opens for business.
> This way we clarly have only one issue tracker at (nearly) all times.  This
> would make a clean migration, and reduce risk of trapping users.
>
> Other opinions?
>
> Thanks,
>
> Mike
> --
> Mike McCandless
>
> http://blog.mikemccandless.com
>

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

Hello - it's my first and last call for volunteers for the GitHub migration.
Sorry, I know few people may be interested in this work. But I didn't want
just to complain as "no one helped me so I had to take over all pains on my
own" without explicitly calling for help.

These are tasks that should be addressed, while I'm still not exactly sure
how to resolve them (although it should be possible and there are some
clues).

- https://github.com/apache/lucene-jira-archive/issues/1
  - this needs knowledge about syntax parsing - and the effort of thorough
debugging with real data.
- https://github.com/apache/lucene-jira-archive/issues/3
  - this might need infra's help.
- https://github.com/apache/lucene-jira-archive/issues/15
  - this needs knowledge about Jira API and might need infra's help.

It's a kind of work you will not be credited (in terms of change log or
commit history), moreover, it may not so exciting to work on - therefore I
would really appreciate your help.

Thanks,
Tomoko


2022年7月1日(金) 16:53 Tomoko Uchida :

> It seems there are no major objections?
>
> A status update - we now have a public ASF repository for the migration
> and all work will be done under it, outside the main lucene repo/Jira/dev
> list.
> https://github.com/apache/lucene-jira-archive
>
> I'm not fully sure how many people are interested in this sub-project;
> just for your information, there are two major blockers (to me).
> - https://github.com/apache/lucene-jira-archive/issues/1
> - https://github.com/apache/lucene-jira-archive/issues/3
>
> Once we successfully address them, the migration will be done in the
> following steps.
> https://github.com/apache/lucene-jira-archive/issues/7
>
> Tomoko
>
>
> 2022年6月29日(水) 15:56 Dawid Weiss :
>
>> I looked at the first random issue and noticed these (perhaps known)
>> issues -
>>
>> https://github.com/mocobeta/sandbox-lucene-10557/issues/10838
>>
>> 1) lists are converted into bold blocks (without the list):
>>
>> https://github.com/mocobeta/sandbox-lucene-10557/issues/10838#issuecomment-1166777318
>>
>> 2) inline images in the description point at nothing.
>>
>> But it's already quite impressive.
>>
>> Dawid
>>
>> On Tue, Jun 28, 2022 at 6:49 PM Tomoko Uchida
>>  wrote:
>> >
>> > I finished the second prototype. With a few exceptions, almost all
>> existing issues were successfully migrated into the test repo. You can
>> browse/search them.
>> > https://github.com/mocobeta/sandbox-lucene-10557/issues
>> >
>> > Some limitations in the first prototype have been addressed. For
>> example, we can preserve the original timestamp of the issues/comments.
>> > I could list improvements and current limitations though, could you try
>> it out yourself; any issues should be found by Jira issue numbers.
>> > Note that "attachments" are still not ported. We've found workarounds
>> so it will be addressed in the next iteration.
>> >
>> > I don't think we reached a conclusion, though, I fully recognize there
>> are strong requests on the atomic switch to GitHub and I haven't seen
>> objections on that so far - then I'll continue to work on improving the
>> migration quality.
>> > I would finish playing around with prototyping and if there are next
>> iterations, these will be rehearsals for the actual migration.
>> >
>> >
>> > Tomoko
>> >
>> >
>> > 2022年6月27日(月) 10:27 Tomoko Uchida :
>> >>
>> >> > It looks like the GitHub Danger Zone can transfer a repository?
>> >>
>> >> "Transferring a repository" creates another repository different from
>> apache/lucene. It'd make the migration process easy though, is it our
>> intention to have an external repository for old issues?
>> >>
>> >> Tomoko
>> >>
>> >>
>> >> 2022年6月27日(月) 8:24 Michael McCandless :
>> >>>
>> >>> It looks like the GitHub Danger Zone can transfer a repository?
>> >>>
>> >>> It's not clear if it can go from Personal -> Organization though.  I
>> see Personal -> Personal and Organization -> Organization.
>> >>>
>> >>>
>> https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
>> >>>
>> >>> Mike McCandless
>> >>>
>> >>> http://blog.mikemccandless.com
>> >>>
>> >>>
>> >>> On Sun, Jun 26, 2022 at 6:40 PM Tomoko Uchida <
>> tomoko.uchida.1...@gmail.com> wrote:

Call for public comments on Which GitHub accont we should/can use for migration

[Tomoko Uchida]

Hello all.
This is the last thing (to me) we would need a consensus on the GitHub
issue migration.

The problem is, that we cannot preserve the original Jira issue/comment
authors since GitHub API assumes the caller's account is the author and
does not allow callers to change it by any means.
I drafted workarounds for that in
https://github.com/apache/lucene-jira-archive/issues/4.

If you have thoughts on that, please read the issue and leave
comments/questions there or make a reply to this mail. (I suppose Uwe has a
strong opinion about this.)
If there are no comments, I'll consider that all the decisions on this
topic are delegated to me; then will proceed with it following infra's
advice.

Tomoko

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

It seems there are no major objections?

A status update - we now have a public ASF repository for the migration and
all work will be done under it, outside the main lucene repo/Jira/dev list.
https://github.com/apache/lucene-jira-archive

I'm not fully sure how many people are interested in this sub-project; just
for your information, there are two major blockers (to me).
- https://github.com/apache/lucene-jira-archive/issues/1
- https://github.com/apache/lucene-jira-archive/issues/3

Once we successfully address them, the migration will be done in the
following steps.
https://github.com/apache/lucene-jira-archive/issues/7

Tomoko


2022年6月29日(水) 15:56 Dawid Weiss :

> I looked at the first random issue and noticed these (perhaps known)
> issues -
>
> https://github.com/mocobeta/sandbox-lucene-10557/issues/10838
>
> 1) lists are converted into bold blocks (without the list):
>
> https://github.com/mocobeta/sandbox-lucene-10557/issues/10838#issuecomment-1166777318
>
> 2) inline images in the description point at nothing.
>
> But it's already quite impressive.
>
> Dawid
>
> On Tue, Jun 28, 2022 at 6:49 PM Tomoko Uchida
>  wrote:
> >
> > I finished the second prototype. With a few exceptions, almost all
> existing issues were successfully migrated into the test repo. You can
> browse/search them.
> > https://github.com/mocobeta/sandbox-lucene-10557/issues
> >
> > Some limitations in the first prototype have been addressed. For
> example, we can preserve the original timestamp of the issues/comments.
> > I could list improvements and current limitations though, could you try
> it out yourself; any issues should be found by Jira issue numbers.
> > Note that "attachments" are still not ported. We've found workarounds so
> it will be addressed in the next iteration.
> >
> > I don't think we reached a conclusion, though, I fully recognize there
> are strong requests on the atomic switch to GitHub and I haven't seen
> objections on that so far - then I'll continue to work on improving the
> migration quality.
> > I would finish playing around with prototyping and if there are next
> iterations, these will be rehearsals for the actual migration.
> >
> >
> > Tomoko
> >
> >
> > 2022年6月27日(月) 10:27 Tomoko Uchida :
> >>
> >> > It looks like the GitHub Danger Zone can transfer a repository?
> >>
> >> "Transferring a repository" creates another repository different from
> apache/lucene. It'd make the migration process easy though, is it our
> intention to have an external repository for old issues?
> >>
> >> Tomoko
> >>
> >>
> >> 2022年6月27日(月) 8:24 Michael McCandless :
> >>>
> >>> It looks like the GitHub Danger Zone can transfer a repository?
> >>>
> >>> It's not clear if it can go from Personal -> Organization though.  I
> see Personal -> Personal and Organization -> Organization.
> >>>
> >>>
> https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
> >>>
> >>> Mike McCandless
> >>>
> >>> http://blog.mikemccandless.com
> >>>
> >>>
> >>> On Sun, Jun 26, 2022 at 6:40 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> 2022年6月27日(月) 5:16 Michael Sokolov :
> >>>>>>
> >>>>>> as for this access control/script monitoring problem, I wonder
> whether
> >>>>>> we could import all the issues into a new github repo owned by
> >>>>>> whomever is running the script, and then transfer from there to the
> >>>>>> lucene repo? It would be an extra step involving another script (or
> >>>>>> something), but maybe(?) that one could be much simpler since it is
> >>>>>> github->github?? If this works out, we could have full control of
> the
> >>>>>> first step and only hand off to infra the simpler copying job.
> >>>>>>
> >>>>>
> >>>>> I don't see the API or tool that transfers all issues from one repo
> to another repo.
> >>>>
> >>>>
> >>>> To be exact, I don't see the API or tool that transfers all issues
> from one repo to another repo while keeping cross-issue links.
> >>>> If we want to preserve cross-issue links, there's no difference
> between "Jira to GitHub&

Re: [GitHub] [lucene-jira-archive] mocobeta opened a new issue, #1: Fix markup conversion error

[Tomoko Uchida]

The notifications are now sent to issues@ list. Still, it could be noisy to
have them in there for many of you, we could not set a fake mail address to
completely silence the notification.
You might want to set a mail filter to screen out the notifications from
the migration repository.

Thanks.


2022年6月29日(水) 20:23 Tomoko Uchida :

> I set https://github.com/apache/lucene-jira-archive/blob/main/.asf.yaml
> to send all notifications to my ASF address, but this did not help...
>
>
>
>
> 2022年6月29日(水) 19:24 Tomoko Uchida :
>
>> Sorry, it seems the all updates in
>> https://github.com/apache/lucene-jira-archive are noticed in dev@ list.
>> I don't see the configuration/setting for the repository. Could anyone
>> mute this?
>>
>> Tomoko
>>
>>
>> 2022年6月29日(水) 19:06 GitBox :
>>
>>>
>>> mocobeta opened a new issue, #1:
>>> URL: https://github.com/apache/lucene-jira-archive/issues/1
>>>
>>>There are various errors in converting Jira markup to Markdown.
>>>
>>>For example:
>>>- tables are broken
>>>- bullet lists converted to bold blocks (?)
>>>- bullet lists include unnecessary spaces between items
>>>- indents are not preserved
>>>- ...
>>>
>>>This issue tries to figure out the root cause of the errors and fix
>>> those.
>>>
>>>
>>> --
>>> This is an automated message from the Apache Git Service.
>>> To respond to the message, please log on to GitHub and use the
>>> URL above to go to the specific comment.
>>>
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org.apache.org
>>>
>>> For queries about this service, please contact Infrastructure at:
>>> us...@infra.apache.org
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>

Re: [GitHub] [lucene-jira-archive] mocobeta opened a new issue, #1: Fix markup conversion error

[Tomoko Uchida]

I set https://github.com/apache/lucene-jira-archive/blob/main/.asf.yaml to
send all notifications to my ASF address, but this did not help...




2022年6月29日(水) 19:24 Tomoko Uchida :

> Sorry, it seems the all updates in
> https://github.com/apache/lucene-jira-archive are noticed in dev@ list.
> I don't see the configuration/setting for the repository. Could anyone
> mute this?
>
> Tomoko
>
>
> 2022年6月29日(水) 19:06 GitBox :
>
>>
>> mocobeta opened a new issue, #1:
>> URL: https://github.com/apache/lucene-jira-archive/issues/1
>>
>>There are various errors in converting Jira markup to Markdown.
>>
>>For example:
>>- tables are broken
>>- bullet lists converted to bold blocks (?)
>>- bullet lists include unnecessary spaces between items
>>- indents are not preserved
>>- ...
>>
>>This issue tries to figure out the root cause of the errors and fix
>> those.
>>
>>
>> --
>> This is an automated message from the Apache Git Service.
>> To respond to the message, please log on to GitHub and use the
>> URL above to go to the specific comment.
>>
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org.apache.org
>>
>> For queries about this service, please contact Infrastructure at:
>> us...@infra.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: [GitHub] [lucene-jira-archive] mocobeta opened a new issue, #1: Fix markup conversion error

[Tomoko Uchida]

Sorry, it seems the all updates in
https://github.com/apache/lucene-jira-archive are noticed in dev@ list.
I don't see the configuration/setting for the repository. Could anyone mute
this?

Tomoko


2022年6月29日(水) 19:06 GitBox :

>
> mocobeta opened a new issue, #1:
> URL: https://github.com/apache/lucene-jira-archive/issues/1
>
>There are various errors in converting Jira markup to Markdown.
>
>For example:
>- tables are broken
>- bullet lists converted to bold blocks (?)
>- bullet lists include unnecessary spaces between items
>- indents are not preserved
>- ...
>
>This issue tries to figure out the root cause of the errors and fix
> those.
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

I finished the second prototype. With a few exceptions, almost all existing
issues were successfully migrated into the test repo. You can browse/search
them.
https://github.com/mocobeta/sandbox-lucene-10557/issues

Some limitations in the first prototype have been addressed. For example,
we can preserve the original timestamp of the issues/comments.
I could list improvements and current limitations though, could you try it
out yourself; any issues should be found by Jira issue numbers.
Note that "attachments" are still not ported. We've found workarounds so it
will be addressed in the next iteration.

I don't think we reached a conclusion, though, I fully recognize there are
strong requests on the atomic switch to GitHub and I haven't seen
objections on that so far - then I'll continue to work on improving the
migration quality.
I would finish playing around with prototyping and if there are next
iterations, these will be rehearsals for the actual migration.


Tomoko


2022年6月27日(月) 10:27 Tomoko Uchida :

> > It looks like the GitHub Danger Zone can transfer a repository?
>
> "Transferring a repository" creates another repository different from
> apache/lucene. It'd make the migration process easy though, is it our
> intention to have an external repository for old issues?
>
> Tomoko
>
>
> 2022年6月27日(月) 8:24 Michael McCandless :
>
>> It looks like the GitHub Danger Zone can transfer a repository?
>>
>> It's not clear if it can go from Personal -> Organization though.  I see
>> Personal -> Personal and Organization -> Organization.
>>
>>
>> https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Sun, Jun 26, 2022 at 6:40 PM Tomoko Uchida <
>> tomoko.uchida.1...@gmail.com> wrote:
>>
>>>
>>>
>>>
>>>
>>>>
>>>> 2022年6月27日(月) 5:16 Michael Sokolov :
>>>>
>>>>> as for this access control/script monitoring problem, I wonder whether
>>>>> we could import all the issues into a new github repo owned by
>>>>> whomever is running the script, and then transfer from there to the
>>>>> lucene repo? It would be an extra step involving another script (or
>>>>> something), but maybe(?) that one could be much simpler since it is
>>>>> github->github?? If this works out, we could have full control of the
>>>>> first step and only hand off to infra the simpler copying job.
>>>>>
>>>>>
>>>> I don't see the API or tool that transfers all issues from one repo to
>>>> another repo.
>>>>
>>>
>>> To be exact, I don't see the API or tool that transfers all issues from
>>> one repo to another repo while keeping cross-issue links.
>>> If we want to preserve cross-issue links, there's no difference between
>>> "Jira to GitHub" and "GitHub to GitHub".
>>>
>>>
>>>>
>>>>> On Sat, Jun 25, 2022 at 7:53 AM Tomoko Uchida
>>>>>  wrote:
>>>>> >
>>>>> > I may have to share another practical consideration on the migration
>>>>> that I haven't mentioned yet.
>>>>> >
>>>>> > We are not allowed to have admin access to the lucene GitHub repo,
>>>>> so can't run the import job(s) on ourselves.
>>>>> > We'll have to make a tool with clear instructions for the migration
>>>>> and pass it to infra team, then support them via the jira (or slack?) if
>>>>> there are any problems.
>>>>> > See https://issues.apache.org/jira/browse/INFRA-20118
>>>>> >
>>>>> > We can do some preparation locally (e.g. dump Jira issues and
>>>>> convert them to importable format to GitHub), but the actual first and
>>>>> second pass import will be done by infra team.
>>>>> > I think I myself won't be able to have close contact with the infra
>>>>> team if the migration operation is too complicated due to the time
>>>>> difference and my communication ability - I'm not good at real-time
>>>>> conversation in English.
>>>>> > So if we need a complex migration plan, I think I'll have to find
>>>>> someone who is willing to take over the job.
>>>>> >
>>>>> >
>>>>> >
>>>>> > 2022年6月25日(土) 19:19 Tomoko Uchida :
>>>>> >>
>

Re: Plan for GitHub issue metadata management

[Tomoko Uchida]

I've prepared issue labels in a test repository. (A test migration is
in progress and not yet completed.)
https://github.com/mocobeta/sandbox-lucene-10557/issues

Thre are four label families.

- type:abcd (Issue Type)
- fixVersion:x.x.x (Fix Versions) [1]
- affectsVersion:x.x.x  (Affects Versions)
- component:module/ (Components)

If you have any suggestions on label management, please feel free to
redesign it. I have no strong opinion on that and may not be able to
take the time to think deliberately about it.

[1] I first thought of using Milestone for versions, but there were a
few questions on it; then I'd keep the current operation: multiple fix
versions.


2022年6月20日(月) 19:10 Tomoko Uchida :
>
> I haven't used the "project" feature either - maybe it could be an
> option but I can't have an opinion on it. Is there anyone who has
> experience with it and wants to lead us to use it?
>
> Tomoko
>
> 2022年6月20日(月) 18:59 Jens Wille :
> >
> > Hi,
> >
> > I'm just a bystander here. But are you aware that the new projects (beta)
> > includes support for custom fields?
> >
> > <https://docs.github.com/en/issues/trying-out-the-new-projects-experience/creating-a-project#adding-custom-fields>
> >
> > I haven't used them myself yet, but it seems that they might be a viable
> > alternative to modeling everything with labels (which is more of a crutch I
> > suppose).
> >
> > Cheers,
> > Jens
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

> It looks like the GitHub Danger Zone can transfer a repository?

"Transferring a repository" creates another repository different from
apache/lucene. It'd make the migration process easy though, is it our
intention to have an external repository for old issues?

Tomoko


2022年6月27日(月) 8:24 Michael McCandless :

> It looks like the GitHub Danger Zone can transfer a repository?
>
> It's not clear if it can go from Personal -> Organization though.  I see
> Personal -> Personal and Organization -> Organization.
>
>
> https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Sun, Jun 26, 2022 at 6:40 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
>>
>>
>>
>>
>>>
>>> 2022年6月27日(月) 5:16 Michael Sokolov :
>>>
>>>> as for this access control/script monitoring problem, I wonder whether
>>>> we could import all the issues into a new github repo owned by
>>>> whomever is running the script, and then transfer from there to the
>>>> lucene repo? It would be an extra step involving another script (or
>>>> something), but maybe(?) that one could be much simpler since it is
>>>> github->github?? If this works out, we could have full control of the
>>>> first step and only hand off to infra the simpler copying job.
>>>>
>>>>
>>> I don't see the API or tool that transfers all issues from one repo to
>>> another repo.
>>>
>>
>> To be exact, I don't see the API or tool that transfers all issues from
>> one repo to another repo while keeping cross-issue links.
>> If we want to preserve cross-issue links, there's no difference between
>> "Jira to GitHub" and "GitHub to GitHub".
>>
>>
>>>
>>>> On Sat, Jun 25, 2022 at 7:53 AM Tomoko Uchida
>>>>  wrote:
>>>> >
>>>> > I may have to share another practical consideration on the migration
>>>> that I haven't mentioned yet.
>>>> >
>>>> > We are not allowed to have admin access to the lucene GitHub repo, so
>>>> can't run the import job(s) on ourselves.
>>>> > We'll have to make a tool with clear instructions for the migration
>>>> and pass it to infra team, then support them via the jira (or slack?) if
>>>> there are any problems.
>>>> > See https://issues.apache.org/jira/browse/INFRA-20118
>>>> >
>>>> > We can do some preparation locally (e.g. dump Jira issues and convert
>>>> them to importable format to GitHub), but the actual first and second pass
>>>> import will be done by infra team.
>>>> > I think I myself won't be able to have close contact with the infra
>>>> team if the migration operation is too complicated due to the time
>>>> difference and my communication ability - I'm not good at real-time
>>>> conversation in English.
>>>> > So if we need a complex migration plan, I think I'll have to find
>>>> someone who is willing to take over the job.
>>>> >
>>>> >
>>>> >
>>>> > 2022年6月25日(土) 19:19 Tomoko Uchida :
>>>> >>
>>>> >> Hi Dawid,
>>>> >>
>>>> >> > Emm.. sorry for being slow - what is it that you want me to do? :)
>>>> Unwatch->Ignore?
>>>> >>
>>>> >> I'm sorry for being ambiguous. Could you set your notification
>>>> setting on the repository as "Participating and @mentions"?
>>>> >> In the testing of migration scripts, I will import many fake issues
>>>> where your account is linked as the original reporter/author with real
>>>> mentions, like this example.
>>>> >> https://github.com/mocobeta/migration-test-1/issues/111
>>>> >> If they do not disturb your inbox with spam notifications then the
>>>> test is successful.
>>>> >>
>>>> >> With regard to attachments:
>>>> >>
>>>> >> > 1) create a (separate?) git repository or branch with a separate
>>>> root in the lucene repository with all jira attachments upon importing 
>>>> them.
>>>> >> > 2) there are about 7k issues with attachments in Jira. We can
>>>> split them into 25-issue batches and ask the crowd to port them manually
>>>>

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

>
> 2022年6月27日(月) 5:16 Michael Sokolov :
>
>> as for this access control/script monitoring problem, I wonder whether
>> we could import all the issues into a new github repo owned by
>> whomever is running the script, and then transfer from there to the
>> lucene repo? It would be an extra step involving another script (or
>> something), but maybe(?) that one could be much simpler since it is
>> github->github?? If this works out, we could have full control of the
>> first step and only hand off to infra the simpler copying job.
>>
>>
> I don't see the API or tool that transfers all issues from one repo to
> another repo.
>

To be exact, I don't see the API or tool that transfers all issues from one
repo to another repo while keeping cross-issue links.
If we want to preserve cross-issue links, there's no difference between
"Jira to GitHub" and "GitHub to GitHub".


>
>> On Sat, Jun 25, 2022 at 7:53 AM Tomoko Uchida
>>  wrote:
>> >
>> > I may have to share another practical consideration on the migration
>> that I haven't mentioned yet.
>> >
>> > We are not allowed to have admin access to the lucene GitHub repo, so
>> can't run the import job(s) on ourselves.
>> > We'll have to make a tool with clear instructions for the migration and
>> pass it to infra team, then support them via the jira (or slack?) if there
>> are any problems.
>> > See https://issues.apache.org/jira/browse/INFRA-20118
>> >
>> > We can do some preparation locally (e.g. dump Jira issues and convert
>> them to importable format to GitHub), but the actual first and second pass
>> import will be done by infra team.
>> > I think I myself won't be able to have close contact with the infra
>> team if the migration operation is too complicated due to the time
>> difference and my communication ability - I'm not good at real-time
>> conversation in English.
>> > So if we need a complex migration plan, I think I'll have to find
>> someone who is willing to take over the job.
>> >
>> >
>> >
>> > 2022年6月25日(土) 19:19 Tomoko Uchida :
>> >>
>> >> Hi Dawid,
>> >>
>> >> > Emm.. sorry for being slow - what is it that you want me to do? :)
>> Unwatch->Ignore?
>> >>
>> >> I'm sorry for being ambiguous. Could you set your notification setting
>> on the repository as "Participating and @mentions"?
>> >> In the testing of migration scripts, I will import many fake issues
>> where your account is linked as the original reporter/author with real
>> mentions, like this example.
>> >> https://github.com/mocobeta/migration-test-1/issues/111
>> >> If they do not disturb your inbox with spam notifications then the
>> test is successful.
>> >>
>> >> With regard to attachments:
>> >>
>> >> > 1) create a (separate?) git repository or branch with a separate
>> root in the lucene repository with all jira attachments upon importing them.
>> >> > 2) there are about 7k issues with attachments in Jira. We can split
>> them into 25-issue batches and ask the crowd to port them manually
>> >>
>> >> Thanks for your suggestion, I don't come up with other options either.
>> Both would need others' permission and/or extra work, so I think we can't
>> control the process and outcome.
>> >> For 1), we'll need to ask infra to create a repository and run another
>> long-running batch, and it'll complicate the migration instructions - we'll
>> not be allowed to have access tokens to commit files to an ASF repo from a
>> program.
>> >> For 2), I'm not sure how many people want to volunteer for the manual
>> work.
>> >>
>> >> I cannot promise it will be eventually done, then I would leave it as
>> a limitation of the migration.
>> >> If there are no controllable solutions (to me) on this, I may ask
>> others if we should migrate existing issues to GitHub "even if we can't
>> migrate any attachments and have to keep them in Jira forever". Let me keep
>> myself neutral about the idea of migrating all Jira issues, sorry... I'm
>> working on this not to push it but to provide information and gain a
>> certain agreement.
>> >>
>> >> Tomoko
>> >>
>> >>
>> >> 2022年6月25日(土) 16:12 Dawid Weiss :
>> >>>
>> >>>
>> >>> Hi Tomoko,
>> >>>
>> >>>>
>> >>>> T

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

2022年6月27日(月) 5:16 Michael Sokolov :

> as for this access control/script monitoring problem, I wonder whether
> we could import all the issues into a new github repo owned by
> whomever is running the script, and then transfer from there to the
> lucene repo? It would be an extra step involving another script (or
> something), but maybe(?) that one could be much simpler since it is
> github->github?? If this works out, we could have full control of the
> first step and only hand off to infra the simpler copying job.
>
>
I don't see the API or tool that transfers all issues from one repo to
another repo.


> On Sat, Jun 25, 2022 at 7:53 AM Tomoko Uchida
>  wrote:
> >
> > I may have to share another practical consideration on the migration
> that I haven't mentioned yet.
> >
> > We are not allowed to have admin access to the lucene GitHub repo, so
> can't run the import job(s) on ourselves.
> > We'll have to make a tool with clear instructions for the migration and
> pass it to infra team, then support them via the jira (or slack?) if there
> are any problems.
> > See https://issues.apache.org/jira/browse/INFRA-20118
> >
> > We can do some preparation locally (e.g. dump Jira issues and convert
> them to importable format to GitHub), but the actual first and second pass
> import will be done by infra team.
> > I think I myself won't be able to have close contact with the infra team
> if the migration operation is too complicated due to the time difference
> and my communication ability - I'm not good at real-time conversation in
> English.
> > So if we need a complex migration plan, I think I'll have to find
> someone who is willing to take over the job.
> >
> >
> >
> > 2022年6月25日(土) 19:19 Tomoko Uchida :
> >>
> >> Hi Dawid,
> >>
> >> > Emm.. sorry for being slow - what is it that you want me to do? :)
> Unwatch->Ignore?
> >>
> >> I'm sorry for being ambiguous. Could you set your notification setting
> on the repository as "Participating and @mentions"?
> >> In the testing of migration scripts, I will import many fake issues
> where your account is linked as the original reporter/author with real
> mentions, like this example.
> >> https://github.com/mocobeta/migration-test-1/issues/111
> >> If they do not disturb your inbox with spam notifications then the test
> is successful.
> >>
> >> With regard to attachments:
> >>
> >> > 1) create a (separate?) git repository or branch with a separate root
> in the lucene repository with all jira attachments upon importing them.
> >> > 2) there are about 7k issues with attachments in Jira. We can split
> them into 25-issue batches and ask the crowd to port them manually
> >>
> >> Thanks for your suggestion, I don't come up with other options either.
> Both would need others' permission and/or extra work, so I think we can't
> control the process and outcome.
> >> For 1), we'll need to ask infra to create a repository and run another
> long-running batch, and it'll complicate the migration instructions - we'll
> not be allowed to have access tokens to commit files to an ASF repo from a
> program.
> >> For 2), I'm not sure how many people want to volunteer for the manual
> work.
> >>
> >> I cannot promise it will be eventually done, then I would leave it as a
> limitation of the migration.
> >> If there are no controllable solutions (to me) on this, I may ask
> others if we should migrate existing issues to GitHub "even if we can't
> migrate any attachments and have to keep them in Jira forever". Let me keep
> myself neutral about the idea of migrating all Jira issues, sorry... I'm
> working on this not to push it but to provide information and gain a
> certain agreement.
> >>
> >> Tomoko
> >>
> >>
> >> 2022年6月25日(土) 16:12 Dawid Weiss :
> >>>
> >>>
> >>> Hi Tomoko,
> >>>
> >>>>
> >>>> There are two ways to receive notifications as you know, 1) watch all
> activities and 2) receive notifications only when you are mentioned
> (default).
> >>>> I excluded your github account from marking up with backticks `` to
> create hyperlinks. Could you unwatch the repo again and then observe your
> inbox for a while, so that we can also test 2)?
> >>>>
> https://github.com/mocobeta/sandbox-lucene-10557/blob/main/migration/src/jira2github_import.py#L21
> >>>
> >>>
> >>> Emm.. sorry for being slow - what is it that you want me to do? :)
> Unwatch->Ignore?
&g

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

I may have to share another practical consideration on the migration that I
haven't mentioned yet.

We are not allowed to have admin access to the lucene GitHub repo, so can't
run the import job(s) on ourselves.
We'll have to make a tool with clear instructions for the migration and
pass it to infra team, then support them via the jira (or slack?) if there
are any problems.
See https://issues.apache.org/jira/browse/INFRA-20118

We can do some preparation locally (e.g. dump Jira issues and convert them
to importable format to GitHub), but the actual first and second pass
import will be done by infra team.
I think I myself won't be able to have close contact with the infra team if
the migration operation is too complicated due to the time difference and
my communication ability - I'm not good at real-time conversation in
English.
So if we need a complex migration plan, I think I'll have to find someone
who is willing to take over the job.



2022年6月25日(土) 19:19 Tomoko Uchida :

> Hi Dawid,
>
> > Emm.. sorry for being slow - what is it that you want me to do? :)
> Unwatch->Ignore?
>
> I'm sorry for being ambiguous. Could you set your notification setting on
> the repository as "Participating and @mentions"?
> In the testing of migration scripts, I will import many fake issues where
> your account is linked as the original reporter/author with real mentions,
> like this example.
> https://github.com/mocobeta/migration-test-1/issues/111
> If they do not disturb your inbox with spam notifications then the test is
> successful.
>
> With regard to attachments:
>
> > 1) create a (separate?) git repository or branch with a separate root in
> the lucene repository with all jira attachments upon importing them.
> > 2) there are about 7k issues with attachments in Jira. We can split them
> into 25-issue batches and ask the crowd to port them manually
>
> Thanks for your suggestion, I don't come up with other options either.
> Both would need others' permission and/or extra work, so I think we can't
> control the process and outcome.
> For 1), we'll need to ask infra to create a repository and run another
> long-running batch, and it'll complicate the migration instructions - we'll
> not be allowed to have access tokens to commit files to an ASF repo from a
> program.
> For 2), I'm not sure how many people want to volunteer for the manual work.
>
> I cannot promise it will be eventually done, then I would leave it as a
> limitation of the migration.
> If there are no controllable solutions (to me) on this, I may ask others
> if we should migrate existing issues to GitHub "even if we can't migrate
> any attachments and have to keep them in Jira forever". Let me keep myself
> neutral about the idea of migrating all Jira issues, sorry... I'm working
> on this not to push it but to provide information and gain a certain
> agreement.
>
> Tomoko
>
>
> 2022年6月25日(土) 16:12 Dawid Weiss :
>
>>
>> Hi Tomoko,
>>
>>
>>> There are two ways to receive notifications as you know, 1) watch all
>>> activities and 2) receive notifications only when you are mentioned
>>> (default).
>>> I excluded your github account from marking up with backticks `` to
>>> create hyperlinks. Could you unwatch the repo again and then observe your
>>> inbox for a while, so that we can also test 2)?
>>>
>>> https://github.com/mocobeta/sandbox-lucene-10557/blob/main/migration/src/jira2github_import.py#L21
>>>
>>
>> Emm.. sorry for being slow - what is it that you want me to do? :)
>> Unwatch->Ignore?
>>
>>
>>> In this Spring issue, the "attachment" link points to the original Jira
>>> file - so they still use Jira as a file server.
>>>
>>
>> Ahh... right. In that case I have two ideas:
>>
>> 1) create a (separate?) git repository or branch with a separate root in
>> the lucene repository with all jira attachments upon importing them. This
>> could be structured in subfolders, for example:
>>
>> jira/xyz/attachment-1.jpg
>>
>> if this repository is checked in to github, the links to attachment could
>> point at the "raw" git-serving service github offers. I'm not sure it emits
>> proper content-types (for images, etc). Alternatively, it could be
>> github-docs, which does serve them properly for static content.
>>
>> It will not support searches, of course, but it will be a consistent copy.
>>
>> 2) there are about 7k issues with attachments in Jira. We can split them
>> into 25-issue batches and ask the crowd to port them manually... It will
>> take time but once the issues are ported, it can be done incrementally over
>> a longer time stretch, no rush there.
>>
>> Dawid
>>
>

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

Hi Dawid,

> Emm.. sorry for being slow - what is it that you want me to do? :)
Unwatch->Ignore?

I'm sorry for being ambiguous. Could you set your notification setting on
the repository as "Participating and @mentions"?
In the testing of migration scripts, I will import many fake issues where
your account is linked as the original reporter/author with real mentions,
like this example.
https://github.com/mocobeta/migration-test-1/issues/111
If they do not disturb your inbox with spam notifications then the test is
successful.

With regard to attachments:

> 1) create a (separate?) git repository or branch with a separate root in
the lucene repository with all jira attachments upon importing them.
> 2) there are about 7k issues with attachments in Jira. We can split them
into 25-issue batches and ask the crowd to port them manually

Thanks for your suggestion, I don't come up with other options either. Both
would need others' permission and/or extra work, so I think we can't
control the process and outcome.
For 1), we'll need to ask infra to create a repository and run another
long-running batch, and it'll complicate the migration instructions - we'll
not be allowed to have access tokens to commit files to an ASF repo from a
program.
For 2), I'm not sure how many people want to volunteer for the manual work.

I cannot promise it will be eventually done, then I would leave it as a
limitation of the migration.
If there are no controllable solutions (to me) on this, I may ask others if
we should migrate existing issues to GitHub "even if we can't migrate any
attachments and have to keep them in Jira forever". Let me keep myself
neutral about the idea of migrating all Jira issues, sorry... I'm working
on this not to push it but to provide information and gain a certain
agreement.

Tomoko


2022年6月25日(土) 16:12 Dawid Weiss :

>
> Hi Tomoko,
>
>
>> There are two ways to receive notifications as you know, 1) watch all
>> activities and 2) receive notifications only when you are mentioned
>> (default).
>> I excluded your github account from marking up with backticks `` to
>> create hyperlinks. Could you unwatch the repo again and then observe your
>> inbox for a while, so that we can also test 2)?
>>
>> https://github.com/mocobeta/sandbox-lucene-10557/blob/main/migration/src/jira2github_import.py#L21
>>
>
> Emm.. sorry for being slow - what is it that you want me to do? :)
> Unwatch->Ignore?
>
>
>> In this Spring issue, the "attachment" link points to the original Jira
>> file - so they still use Jira as a file server.
>>
>
> Ahh... right. In that case I have two ideas:
>
> 1) create a (separate?) git repository or branch with a separate root in
> the lucene repository with all jira attachments upon importing them. This
> could be structured in subfolders, for example:
>
> jira/xyz/attachment-1.jpg
>
> if this repository is checked in to github, the links to attachment could
> point at the "raw" git-serving service github offers. I'm not sure it emits
> proper content-types (for images, etc). Alternatively, it could be
> github-docs, which does serve them properly for static content.
>
> It will not support searches, of course, but it will be a consistent copy.
>
> 2) there are about 7k issues with attachments in Jira. We can split them
> into 25-issue batches and ask the crowd to port them manually... It will
> take time but once the issues are ported, it can be done incrementally over
> a longer time stretch, no rush there.
>
> Dawid
>

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

Hi Houston and Dawid,
Thanks so much for your help. I might use other test repos but when I try
to migrate a large portion of issues I post them to
https://github.com/mocobeta/sandbox-lucene-10557.

> So did I.

There are two ways to receive notifications as you know, 1) watch all
activities and 2) receive notifications only when you are mentioned
(default).
I excluded your github account from marking up with backticks `` to create
hyperlinks. Could you unwatch the repo again and then observe your inbox
for a while, so that we can also test 2)?
https://github.com/mocobeta/sandbox-lucene-10557/blob/main/migration/src/jira2github_import.py#L21

> How did they import attachment with this API? I can't find this
> anywhere and they definitely did it somehow.

To the best of my knowledge, there is no option to upload/import
attachments to GitHub. "Import issues" API allows users to import only
texts.
In this Spring issue, the "attachment" link points to the original Jira
file - so they still use Jira as a file server. We could do the same by
rewriting all attachment links and actually I was thinking of that once as
an easy workaround. Not sure if it's ethically correct.
https://github.com/spring-projects/spring-data-commons/issues/1080

I still do not figure out the way to copy attachments to GItHub. Direct
link to file urls in Jira (as the Spring issue does) is a somewhat abusive
use of hyperlinks to me, and besides ethics, I think there might be risks
that such direct access to files are banned from Jira servers in the future.

Tomoko


2022年6月25日(土) 4:50 Dawid Weiss :

> > I've subscribed to all notifications for that sandbox-lucene-10557 repo.
> Let me know if you are going to create a different repo and I'll subscribe
> to that as well.
>
> So did I.
>
> How did they import attachment with this API? I can't find this
> anywhere and they definitely did it somehow.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

I started to play around with the (unofficial) Issue Import API
<https://gist.github.com/jonmagic/5282384165e0f86ef105> and so far so good.
- Original timestamps (created, updated) are preserved
- An issue and its comments can be imported with one post request;
importing is done asynchronously but the background job looks sufficiently
fast.
- Notifications are not triggered with mentions in the issue comments
(e.g. https://github.com/mocobeta/sandbox-lucene-10557/issues/249)

I will do more tests and rewrite the scripts with this API and if it works
as expected, try to migrate whole Jira issues into a test repo next time;
it still needs two-pass migration but could be done in a few hours with the
default rate limit.
Is there anybody who kindly provides a github account to make sure that
"any notifications are never triggered" when executing migration? I
confirmed this with my account, just wanted to test it with other one or
two accounts.

Tomoko

2022年6月24日(金) 21:12 Adrien Grand :

> FWIW I don't mind receiving these one-time notifications for the purpose
> of the migration.
>
> On Fri, Jun 24, 2022 at 12:58 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
>> > If you could give me some "example mail", I can add a "feed to trash"
>> sieve rule before you start it.
>>
>> If we decide to migrate all Jira issues to GItHub with reporter/author
>> account re-mapping (hyperlinks), and we still cannot find a workaround
>> not to trigger notifications, I'll let you all know the example mail
>> text.
>> I can also trigger some real notifications by simulating a few
>> migrations for people who wish to know what will happen in their
>> mailbox/github UI beforehand. I'm really not sure what will happen to
>> everyone by triggering so many notifications.
>>
>> Precisely speaking, you will receive the same number of notifications
>> to your all activities in Jira so far: reporting an issue, assigning
>> yourself to an issue, and leaving a comment.
>> GitHub UI and mailers will aggregate them into "issues", I think.
>>
>> > Another question: With the alternative API is it possible to keep
>> original Reporters and Authors of comments, too?
>>
>> I haven't tried the unofficial API yet, but as far as I read the
>> examples, it is not possible to keep original reporters or authors.
>> You cannot change/tweak GitHub issue reporter or author by any means -
>> it looks a sane decision to me.
>>
>>
>> 2022年6月24日(金) 16:18 Uwe Schindler :
>> >
>> > Hi,
>> >
>> > Am 23.06.2022 um 19:09 schrieb Tomoko Uchida:
>> >
>> > uschindler,Uwe Schindler,2474
>> >
>> > If you could give me some "example mail", I can add a "feed to trash"
>> sieve rule before you start it.
>> >
>> > We have 109158 resources (10608 issues + 98550 comments) in total. With
>> the default rate limit of 5000 reqs per hour, it will take 22 hours if
>> there are no failures/retries. With an enterprise account, it will take 7-8
>> hours I think.
>> >
>> > So a sieve rule would be good to not get constant mail all the time,
>> because my 2474 issues (or notifications?) will be distrubuted over the
>> whole day.
>> >
>> > Another question: With the alternative API is it possible to keep
>> original Reporters and Authors of comments, too?
>> >
>> > Uwe
>> >
>> > Tomoko
>> >
>> >
>> > 2022年6月24日(金) 0:39 Tomoko Uchida :
>> >>
>> >> It seems not new - I don't figure out why this is not published as a
>> public API yet but according to the comments there, it could be
>> buggy/unstable (still worth a try to me).
>> >>
>> >>
>> >>
>> >> 2022年6月24日(金) 0:26 Tomoko Uchida :
>> >>>
>> >>> I just browsed through this article about the "import issues" API
>> (looks pretty new and on technical preview status?)
>> >>> https://gist.github.com/jonmagic/5282384165e0f86ef105
>> >>>
>> >>> Seems it solves many of our considerations - preserving original
>> timestamp, bulk importing issue comments, and not triggering notifications.
>> >>>
>> >>> I'll try it later; thank you Rob for providing the information.
>> >>>
>> >>>
>> >>> 2022年6月23日(木) 23:18 Michael Sokolov :
>> >>>>
>> >>>> oh phew! glad to hear this was expected
>> >>>>
>> >>>> On Thu, Jun 23, 2022 at 10:17 AM Tomoko

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

> If you could give me some "example mail", I can add a "feed to trash" sieve 
> rule before you start it.

If we decide to migrate all Jira issues to GItHub with reporter/author
account re-mapping (hyperlinks), and we still cannot find a workaround
not to trigger notifications, I'll let you all know the example mail
text.
I can also trigger some real notifications by simulating a few
migrations for people who wish to know what will happen in their
mailbox/github UI beforehand. I'm really not sure what will happen to
everyone by triggering so many notifications.

Precisely speaking, you will receive the same number of notifications
to your all activities in Jira so far: reporting an issue, assigning
yourself to an issue, and leaving a comment.
GitHub UI and mailers will aggregate them into "issues", I think.

> Another question: With the alternative API is it possible to keep original 
> Reporters and Authors of comments, too?

I haven't tried the unofficial API yet, but as far as I read the
examples, it is not possible to keep original reporters or authors.
You cannot change/tweak GitHub issue reporter or author by any means -
it looks a sane decision to me.


2022年6月24日(金) 16:18 Uwe Schindler :
>
> Hi,
>
> Am 23.06.2022 um 19:09 schrieb Tomoko Uchida:
>
> uschindler,Uwe Schindler,2474
>
> If you could give me some "example mail", I can add a "feed to trash" sieve 
> rule before you start it.
>
> We have 109158 resources (10608 issues + 98550 comments) in total. With the 
> default rate limit of 5000 reqs per hour, it will take 22 hours if there are 
> no failures/retries. With an enterprise account, it will take 7-8 hours I 
> think.
>
> So a sieve rule would be good to not get constant mail all the time, because 
> my 2474 issues (or notifications?) will be distrubuted over the whole day.
>
> Another question: With the alternative API is it possible to keep original 
> Reporters and Authors of comments, too?
>
> Uwe
>
> Tomoko
>
>
> 2022年6月24日(金) 0:39 Tomoko Uchida :
>>
>> It seems not new - I don't figure out why this is not published as a public 
>> API yet but according to the comments there, it could be buggy/unstable 
>> (still worth a try to me).
>>
>>
>>
>> 2022年6月24日(金) 0:26 Tomoko Uchida :
>>>
>>> I just browsed through this article about the "import issues" API (looks 
>>> pretty new and on technical preview status?)
>>> https://gist.github.com/jonmagic/5282384165e0f86ef105
>>>
>>> Seems it solves many of our considerations - preserving original timestamp, 
>>> bulk importing issue comments, and not triggering notifications.
>>>
>>> I'll try it later; thank you Rob for providing the information.
>>>
>>>
>>> 2022年6月23日(木) 23:18 Michael Sokolov :
>>>>
>>>> oh phew! glad to hear this was expected
>>>>
>>>> On Thu, Jun 23, 2022 at 10:17 AM Tomoko Uchida
>>>>  wrote:
>>>> >
>>>> > > Many comments were lost in the transfer. The last one in the copy is
>>>> > > only about 1/4 of the way through this gigantic issue. This really is
>>>> > > a blocker I think.
>>>> >
>>>> > I limited the number of comments per issue up to ten for testing. We can 
>>>> > migrate literally all comments - one by one.
>>>> >
>>>> > Tomoko
>>>> >
>>>> >
>>>> > 2022年6月23日(木) 23:09 Tomoko Uchida :
>>>> >>
>>>> >> Hi,
>>>> >> I have little now to carefully read/respond to all replies right now, 
>>>> >> but just wanted to answer this.
>>>> >>
>>>> >> > Will it be possible to preserve links from issues -> pull requests?
>>>> >>
>>>> >> Yes it's a bit cumbersome (and it could be difficult to make sure that 
>>>> >> all links to PRs are covered - it's not solid metadata, you need to 
>>>> >> parse github bot's comments) but surely possible.
>>>> >> See https://github.com/mocobeta/sandbox-lucene-10557/issues/188.
>>>> >>
>>>> >> As for notifications and attachment files, if there are ways to manage 
>>>> >> these it'd be great.
>>>> >>
>>>> >>
>>>> >> 2022年6月23日(木) 22:59 Dawid Weiss :
>>>> >>>
>>>> >>>
>>>> >>> Interesting, thanks Rob. I see the attachments have been ported in 
>>>> >>> that a

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

> * I don’t think a flood of notifications from the import is a problem.
It’s a one time hassle, and having the actual user links is nice for
GitHub’s cross linking system.

> I agree with Ryan - I'd be willing to bulk-delete 1000 notifications if
it means preserving hyperlinks to people

I'd share some stats.
If we don't (can't) mute the notifications at migration, each issue
reporter/assignee/comment author will receive notifications as listed in
this sheet.
https://docs.google.com/spreadsheets/d/1rt6wO4ZiAw7V2DpqqCU3Ebkc7L_NMZBKaU3fkNjgsi4/edit?usp=sharing

These are the top 10 developers who will receive notifications the most. If
you are okay with that, I can live with it (I only have 159 notifications).

mikemccand,Michael McCandless,3680
rcmuir,Robert Muir,3447
uschindler,Uwe Schindler,2474
jpountz,Adrien Grand,2390
sarowe,Steven Rowe,925
dweiss,Dawid Weiss,908
simonw,Simon Willnauer,845
dsmiley,David Smiley,784
hossman,Chris M. Hostetter,734
shaie,Shai Erera,671

> * Do you have an estimate for how many api calls are needed? How many
total issues+comments exist in jira? I assume the limits you dealt with
were the default 5k requests per hour. If that will take too long, we could
consider using a user from an enterprise account which has 3x the limit.

We have 109158 resources (10608 issues + 98550 comments) in total. With the
default rate limit of 5000 reqs per hour, it will take 22 hours if there
are no failures/retries. With an enterprise account, it will take 7-8 hours
I think.


Tomoko


2022年6月24日(金) 0:39 Tomoko Uchida :

> It seems not new - I don't figure out why this is not published as a
> public API yet but according to the comments there, it could be
> buggy/unstable (still worth a try to me).
>
>
>
> 2022年6月24日(金) 0:26 Tomoko Uchida :
>
>> I just browsed through this article about the "import issues" API (looks
>> pretty new and on technical preview status?)
>> https://gist.github.com/jonmagic/5282384165e0f86ef105
>>
>> Seems it solves many of our considerations - preserving original
>> timestamp, bulk importing issue comments, and not triggering notifications.
>>
>> I'll try it later; thank you Rob for providing the information.
>>
>>
>> 2022年6月23日(木) 23:18 Michael Sokolov :
>>
>>> oh phew! glad to hear this was expected
>>>
>>> On Thu, Jun 23, 2022 at 10:17 AM Tomoko Uchida
>>>  wrote:
>>> >
>>> > > Many comments were lost in the transfer. The last one in the copy is
>>> > > only about 1/4 of the way through this gigantic issue. This really is
>>> > > a blocker I think.
>>> >
>>> > I limited the number of comments per issue up to ten for testing. We
>>> can migrate literally all comments - one by one.
>>> >
>>> > Tomoko
>>> >
>>> >
>>> > 2022年6月23日(木) 23:09 Tomoko Uchida :
>>> >>
>>> >> Hi,
>>> >> I have little now to carefully read/respond to all replies right now,
>>> but just wanted to answer this.
>>> >>
>>> >> > Will it be possible to preserve links from issues -> pull requests?
>>> >>
>>> >> Yes it's a bit cumbersome (and it could be difficult to make sure
>>> that all links to PRs are covered - it's not solid metadata, you need to
>>> parse github bot's comments) but surely possible.
>>> >> See https://github.com/mocobeta/sandbox-lucene-10557/issues/188.
>>> >>
>>> >> As for notifications and attachment files, if there are ways to
>>> manage these it'd be great.
>>> >>
>>> >>
>>> >> 2022年6月23日(木) 22:59 Dawid Weiss :
>>> >>>
>>> >>>
>>> >>> Interesting, thanks Rob. I see the attachments have been ported in
>>> that article as well - something the official API is not able to do.
>>> >>>
>>> >>> https://jira.spring.io/browse/DATACMNS-617?redirect=false
>>> >>> https://github.com/spring-projects/spring-data-commons/issues/1080
>>> >>>
>>> >>> Dawid
>>> >>>
>>> >>> On Thu, Jun 23, 2022 at 3:26 PM Rob Audenaerde <
>>> rob.audenae...@gmail.com> wrote:
>>> >>>>
>>> >>>> I didn't read the entire thread, so apologies if this is a
>>> duplicate:
>>> >>>>
>>> >>>> Did you check
>>> https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues
>>> >>>>
>>> >>>> They especially wri

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

It seems not new - I don't figure out why this is not published as a public
API yet but according to the comments there, it could be buggy/unstable
(still worth a try to me).



2022年6月24日(金) 0:26 Tomoko Uchida :

> I just browsed through this article about the "import issues" API (looks
> pretty new and on technical preview status?)
> https://gist.github.com/jonmagic/5282384165e0f86ef105
>
> Seems it solves many of our considerations - preserving original
> timestamp, bulk importing issue comments, and not triggering notifications.
>
> I'll try it later; thank you Rob for providing the information.
>
>
> 2022年6月23日(木) 23:18 Michael Sokolov :
>
>> oh phew! glad to hear this was expected
>>
>> On Thu, Jun 23, 2022 at 10:17 AM Tomoko Uchida
>>  wrote:
>> >
>> > > Many comments were lost in the transfer. The last one in the copy is
>> > > only about 1/4 of the way through this gigantic issue. This really is
>> > > a blocker I think.
>> >
>> > I limited the number of comments per issue up to ten for testing. We
>> can migrate literally all comments - one by one.
>> >
>> > Tomoko
>> >
>> >
>> > 2022年6月23日(木) 23:09 Tomoko Uchida :
>> >>
>> >> Hi,
>> >> I have little now to carefully read/respond to all replies right now,
>> but just wanted to answer this.
>> >>
>> >> > Will it be possible to preserve links from issues -> pull requests?
>> >>
>> >> Yes it's a bit cumbersome (and it could be difficult to make sure that
>> all links to PRs are covered - it's not solid metadata, you need to parse
>> github bot's comments) but surely possible.
>> >> See https://github.com/mocobeta/sandbox-lucene-10557/issues/188.
>> >>
>> >> As for notifications and attachment files, if there are ways to manage
>> these it'd be great.
>> >>
>> >>
>> >> 2022年6月23日(木) 22:59 Dawid Weiss :
>> >>>
>> >>>
>> >>> Interesting, thanks Rob. I see the attachments have been ported in
>> that article as well - something the official API is not able to do.
>> >>>
>> >>> https://jira.spring.io/browse/DATACMNS-617?redirect=false
>> >>> https://github.com/spring-projects/spring-data-commons/issues/1080
>> >>>
>> >>> Dawid
>> >>>
>> >>> On Thu, Jun 23, 2022 at 3:26 PM Rob Audenaerde <
>> rob.audenae...@gmail.com> wrote:
>> >>>>
>> >>>> I didn't read the entire thread, so apologies if this is a duplicate:
>> >>>>
>> >>>> Did you check
>> https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues
>> >>>>
>> >>>> They especially write there is an api that doesn't trigger
>> notifications.
>> >>>>
>> >>>> It is documented here:
>> https://gist.github.com/jonmagic/5282384165e0f86ef105
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Thu, Jun 23, 2022, 15:14 Michael Sokolov 
>> wrote:
>> >>>>>
>> >>>>> Yes thank you! You say this is not difficult, but it looks like a
>> big
>> >>>>> job to me! Here are a bunch of things I noticed that we would
>> ideally
>> >>>>> address (from looking at one long and complex issue, LUCENE-9004). I
>> >>>>> wouldn't be so bold as to say these should block us from proceeding
>> if
>> >>>>> they're not addressed, just want to point out there is potentially a
>> >>>>> lot to do:
>> >>>>>
>> >>>>> Will it be possible to preserve links from issues -> pull requests?
>> >>>>> That seems like one of the most important pieces of "metadata".
>> >>>>>
>> >>>>> As far as attached files go, I see you seem to have made an attempt?
>> >>>>> There is a link in
>> https://issues.apache.org/jira/browse/LUCENE-9004
>> >>>>> where you had posted a picture of a graph, for example; in
>> >>>>> https://github.com/mocobeta/sandbox-lucene-10557/issues/171 it is
>> >>>>> represented as a link. When you click on the link you get an error
>> >>>>> though. I wonder if it would be possible to link back to the ima

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

I just browsed through this article about the "import issues" API (looks
pretty new and on technical preview status?)
https://gist.github.com/jonmagic/5282384165e0f86ef105

Seems it solves many of our considerations - preserving original timestamp,
bulk importing issue comments, and not triggering notifications.

I'll try it later; thank you Rob for providing the information.


2022年6月23日(木) 23:18 Michael Sokolov :

> oh phew! glad to hear this was expected
>
> On Thu, Jun 23, 2022 at 10:17 AM Tomoko Uchida
>  wrote:
> >
> > > Many comments were lost in the transfer. The last one in the copy is
> > > only about 1/4 of the way through this gigantic issue. This really is
> > > a blocker I think.
> >
> > I limited the number of comments per issue up to ten for testing. We can
> migrate literally all comments - one by one.
> >
> > Tomoko
> >
> >
> > 2022年6月23日(木) 23:09 Tomoko Uchida :
> >>
> >> Hi,
> >> I have little now to carefully read/respond to all replies right now,
> but just wanted to answer this.
> >>
> >> > Will it be possible to preserve links from issues -> pull requests?
> >>
> >> Yes it's a bit cumbersome (and it could be difficult to make sure that
> all links to PRs are covered - it's not solid metadata, you need to parse
> github bot's comments) but surely possible.
> >> See https://github.com/mocobeta/sandbox-lucene-10557/issues/188.
> >>
> >> As for notifications and attachment files, if there are ways to manage
> these it'd be great.
> >>
> >>
> >> 2022年6月23日(木) 22:59 Dawid Weiss :
> >>>
> >>>
> >>> Interesting, thanks Rob. I see the attachments have been ported in
> that article as well - something the official API is not able to do.
> >>>
> >>> https://jira.spring.io/browse/DATACMNS-617?redirect=false
> >>> https://github.com/spring-projects/spring-data-commons/issues/1080
> >>>
> >>> Dawid
> >>>
> >>> On Thu, Jun 23, 2022 at 3:26 PM Rob Audenaerde <
> rob.audenae...@gmail.com> wrote:
> >>>>
> >>>> I didn't read the entire thread, so apologies if this is a duplicate:
> >>>>
> >>>> Did you check
> https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues
> >>>>
> >>>> They especially write there is an api that doesn't trigger
> notifications.
> >>>>
> >>>> It is documented here:
> https://gist.github.com/jonmagic/5282384165e0f86ef105
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Jun 23, 2022, 15:14 Michael Sokolov 
> wrote:
> >>>>>
> >>>>> Yes thank you! You say this is not difficult, but it looks like a big
> >>>>> job to me! Here are a bunch of things I noticed that we would ideally
> >>>>> address (from looking at one long and complex issue, LUCENE-9004). I
> >>>>> wouldn't be so bold as to say these should block us from proceeding
> if
> >>>>> they're not addressed, just want to point out there is potentially a
> >>>>> lot to do:
> >>>>>
> >>>>> Will it be possible to preserve links from issues -> pull requests?
> >>>>> That seems like one of the most important pieces of "metadata".
> >>>>>
> >>>>> As far as attached files go, I see you seem to have made an attempt?
> >>>>> There is a link in https://issues.apache.org/jira/browse/LUCENE-9004
> >>>>> where you had posted a picture of a graph, for example; in
> >>>>> https://github.com/mocobeta/sandbox-lucene-10557/issues/171 it is
> >>>>> represented as a link. When you click on the link you get an error
> >>>>> though. I wonder if it would be possible to link back to the images
> >>>>> hosted in JIRA? (Ideally as an  tag; otherwise a link would be
> >>>>> good).
> >>>>>
> >>>>> I agree with Ryan - I'd be willing to bulk-delete 1000 notifications
> >>>>> if it means preserving hyperlinks to people
> >>>>>
> >>>>> Numbered list formatting became giant bold text (see the comment
> >>>>> containing "Here's a strategy")
> >>>>>
> >>>>> Many comments were lost in the transfer. The last one in the copy is
&g

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

> Many comments were lost in the transfer. The last one in the copy is
> only about 1/4 of the way through this gigantic issue. This really is
> a blocker I think.

I limited the number of comments per issue up to ten for testing. We can
migrate literally all comments - one by one.

Tomoko


2022年6月23日(木) 23:09 Tomoko Uchida :

> Hi,
> I have little now to carefully read/respond to all replies right now, but
> just wanted to answer this.
>
> > Will it be possible to preserve links from issues -> pull requests?
>
> Yes it's a bit cumbersome (and it could be difficult to make sure that all
> links to PRs are covered - it's not solid metadata, you need to parse
> github bot's comments) but surely possible.
> See https://github.com/mocobeta/sandbox-lucene-10557/issues/188.
>
> As for notifications and attachment files, if there are ways to manage
> these it'd be great.
>
>
> 2022年6月23日(木) 22:59 Dawid Weiss :
>
>>
>> Interesting, thanks Rob. I see the attachments have been ported in that
>> article as well - something the official API is not able to do.
>>
>> https://jira.spring.io/browse/DATACMNS-617?redirect=false
>> https://github.com/spring-projects/spring-data-commons/issues/1080
>>
>> Dawid
>>
>> On Thu, Jun 23, 2022 at 3:26 PM Rob Audenaerde 
>> wrote:
>>
>>> I didn't read the entire thread, so apologies if this is a duplicate:
>>>
>>> Did you check
>>> https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues
>>>
>>> They especially write there is an api that doesn't trigger notifications.
>>>
>>> It is documented here:
>>> https://gist.github.com/jonmagic/5282384165e0f86ef105
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 23, 2022, 15:14 Michael Sokolov  wrote:
>>>
>>>> Yes thank you! You say this is not difficult, but it looks like a big
>>>> job to me! Here are a bunch of things I noticed that we would ideally
>>>> address (from looking at one long and complex issue, LUCENE-9004). I
>>>> wouldn't be so bold as to say these should block us from proceeding if
>>>> they're not addressed, just want to point out there is potentially a
>>>> lot to do:
>>>>
>>>> Will it be possible to preserve links from issues -> pull requests?
>>>> That seems like one of the most important pieces of "metadata".
>>>>
>>>> As far as attached files go, I see you seem to have made an attempt?
>>>> There is a link in https://issues.apache.org/jira/browse/LUCENE-9004
>>>> where you had posted a picture of a graph, for example; in
>>>> https://github.com/mocobeta/sandbox-lucene-10557/issues/171 it is
>>>> represented as a link. When you click on the link you get an error
>>>> though. I wonder if it would be possible to link back to the images
>>>> hosted in JIRA? (Ideally as an  tag; otherwise a link would be
>>>> good).
>>>>
>>>> I agree with Ryan - I'd be willing to bulk-delete 1000 notifications
>>>> if it means preserving hyperlinks to people
>>>>
>>>> Numbered list formatting became giant bold text (see the comment
>>>> containing "Here's a strategy")
>>>>
>>>> Many comments were lost in the transfer. The last one in the copy is
>>>> only about 1/4 of the way through this gigantic issue. This really is
>>>> a blocker I think. I wonder what happened? Maybe some API calls failed
>>>> and we need to retry???
>>>>
>>>> I wanted to check other fancy formatting (tables, block comments, code
>>>> blocks, etc) but haven't looked at these yet...
>>>>
>>>> On Wed, Jun 22, 2022 at 8:34 AM Ryan Ernst  wrote:
>>>> >
>>>> > This is great work Tomoko! A couple minor thoughts:
>>>> >
>>>> > * I don’t think a flood of notifications from the import is a
>>>> problem. It’s a one time hassle, and having the actual user links is nice
>>>> for GitHub’s cross linking system.
>>>> >
>>>> > * Do you have an estimate for how many api calls are needed? How many
>>>> total issues+comments exist in jira? I assume the limits you dealt with
>>>> were the default 5k requests per hour. If that will take too long, we could
>>>> consider using a user from an enterprise account which has 3x the limit.
>>>> >
>>>> > On Tue, Jun 21, 2022 at 15:56 T

Re: A prototype migration tool Jira to GitHub

[Tomoko Uchida]

Hi,
I have little now to carefully read/respond to all replies right now, but
just wanted to answer this.

> Will it be possible to preserve links from issues -> pull requests?

Yes it's a bit cumbersome (and it could be difficult to make sure that all
links to PRs are covered - it's not solid metadata, you need to parse
github bot's comments) but surely possible.
See https://github.com/mocobeta/sandbox-lucene-10557/issues/188.

As for notifications and attachment files, if there are ways to manage
these it'd be great.


2022年6月23日(木) 22:59 Dawid Weiss :

>
> Interesting, thanks Rob. I see the attachments have been ported in that
> article as well - something the official API is not able to do.
>
> https://jira.spring.io/browse/DATACMNS-617?redirect=false
> https://github.com/spring-projects/spring-data-commons/issues/1080
>
> Dawid
>
> On Thu, Jun 23, 2022 at 3:26 PM Rob Audenaerde 
> wrote:
>
>> I didn't read the entire thread, so apologies if this is a duplicate:
>>
>> Did you check
>> https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues
>>
>> They especially write there is an api that doesn't trigger notifications.
>>
>> It is documented here:
>> https://gist.github.com/jonmagic/5282384165e0f86ef105
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 23, 2022, 15:14 Michael Sokolov  wrote:
>>
>>> Yes thank you! You say this is not difficult, but it looks like a big
>>> job to me! Here are a bunch of things I noticed that we would ideally
>>> address (from looking at one long and complex issue, LUCENE-9004). I
>>> wouldn't be so bold as to say these should block us from proceeding if
>>> they're not addressed, just want to point out there is potentially a
>>> lot to do:
>>>
>>> Will it be possible to preserve links from issues -> pull requests?
>>> That seems like one of the most important pieces of "metadata".
>>>
>>> As far as attached files go, I see you seem to have made an attempt?
>>> There is a link in https://issues.apache.org/jira/browse/LUCENE-9004
>>> where you had posted a picture of a graph, for example; in
>>> https://github.com/mocobeta/sandbox-lucene-10557/issues/171 it is
>>> represented as a link. When you click on the link you get an error
>>> though. I wonder if it would be possible to link back to the images
>>> hosted in JIRA? (Ideally as an  tag; otherwise a link would be
>>> good).
>>>
>>> I agree with Ryan - I'd be willing to bulk-delete 1000 notifications
>>> if it means preserving hyperlinks to people
>>>
>>> Numbered list formatting became giant bold text (see the comment
>>> containing "Here's a strategy")
>>>
>>> Many comments were lost in the transfer. The last one in the copy is
>>> only about 1/4 of the way through this gigantic issue. This really is
>>> a blocker I think. I wonder what happened? Maybe some API calls failed
>>> and we need to retry???
>>>
>>> I wanted to check other fancy formatting (tables, block comments, code
>>> blocks, etc) but haven't looked at these yet...
>>>
>>> On Wed, Jun 22, 2022 at 8:34 AM Ryan Ernst  wrote:
>>> >
>>> > This is great work Tomoko! A couple minor thoughts:
>>> >
>>> > * I don’t think a flood of notifications from the import is a problem.
>>> It’s a one time hassle, and having the actual user links is nice for
>>> GitHub’s cross linking system.
>>> >
>>> > * Do you have an estimate for how many api calls are needed? How many
>>> total issues+comments exist in jira? I assume the limits you dealt with
>>> were the default 5k requests per hour. If that will take too long, we could
>>> consider using a user from an enterprise account which has 3x the limit.
>>> >
>>> > On Tue, Jun 21, 2022 at 15:56 Tomoko Uchida <
>>> tomoko.uchida.1...@gmail.com> wrote:
>>> >>
>>> >> Hi all,
>>> >> again - this is about GitHub migration.
>>> >>
>>> >> We have a large disagreement on whether we should migrate existing
>>> Jira issues (including all closed issues) to GitHub or not.
>>> >>
>>> >> I drafted a tiny migration tool [1] to see how it looks if we move
>>> Jira issues to GitHub, and tried to migrate a small portion of Jira
>>> issues/comments to a test repo. You can see it here:
>>> >> - Closed issues list
>>> https://github.com/mocobeta/sandbox-lucene-1

A prototype migration tool Jira to GitHub

[Tomoko Uchida]

Hi all,
again - this is about GitHub migration.

We have a large disagreement on whether we should migrate existing Jira
issues (including all closed issues) to GitHub or not.

I drafted a tiny migration tool [1] to see how it looks if we move Jira
issues to GitHub, and tried to migrate a small portion of Jira
issues/comments to a test repo. You can see it here:
- Closed issues list
https://github.com/mocobeta/sandbox-lucene-10557/issues?q=is%3Aissue+is%3Aclosed
- Unresolved issues list:
https://github.com/mocobeta/sandbox-lucene-10557/issues

I don't deserve to have a strong opinion on how we should treat 20+ years
of history so I would reserve my opinion - would the prototype be of some
help to have a conversation?
I have to leave for a while, I'd be glad if you have a talk on it while I'm
away and hopefully reach an agreement.

Here's a summary of what can be done.

You can:
* migrate all texts in issue descriptions and comments to GitHub;
browsing/searching old issues should work fine.
* extract every issue metadata from Jira and port it to labels or issue
descriptions (as plain text).
* map Jira cross-issue link "LUCENE-xxx" to GitHub issue mention "#yyy".
   * see this example:
https://github.com/mocobeta/sandbox-lucene-10557/issues/218
* map Jira user ids to GitHub accounts if the mapping is given.
* convert Jira markups to Markdown with parser library.
   * not perfect - there can be many conversion errors

And here are the limitations. (Please correct me if I'm missing something.)

You cannot:
* simulate original authors and timestamps; they have to be preserved in
free-text forms.
* migrate attached files (patches, images, etc.) to GitHub; these have to
remain in Jira.
   * it's not allowed to programmatically upload files and attach them to
issues.
* create hyperlinks from issues to GitHub accounts (reporters, comment
authors, etc.) by mentions; otherwise everyone will receive a huge volume
of notifications.
   * still accounts can be noted with a markup `@` (without mentioning)
in their right place
* "bulk" import issues/comments. Each resource has to be posted one by one.
Migration would take many hours (perhaps days?) due to the severe API call
rate limit.

It's not a particularly difficult task, however, there will be other
uncontrollable things I haven't noticed yet.

[1] https://github.com/mocobeta/sandbox-lucene-10557/tree/main/migration

Tomoko

Accidental mentions on GitHub (relates to LUCENE-10557)

[Tomoko Uchida]

Hi,
I think there are people who received GitHub mentions from the test
repository for LUCENE-10557.

Apologies for the noise, it was accidental. I'll convert all mentions
in existing jira issues not to send mentions to anyone when testing
migration scripts.

Tomoko

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

Thanks for your suggestions; actually ASF should have information on
the account mapping.
For now, I'll just prepare scripts to embed the mapped github accounts
next to the jira author/assignee name; we could ask infra or create
the mapping on our own by inference if we find it's worthwhile to have
it.

I think we can discuss "how" on the issue (LUCENE-10557) - I don't
think there are not so many people who are interested in the full
details of such matters, it's practically important though.

2022年6月20日(月) 21:26 Michael Sokolov :
>
> I think the user mapping must be inferred based on membership in the
> Apache "organization" https://github.com/settings/organizations
>
> On Sun, Jun 19, 2022 at 2:45 AM Dawid Weiss  wrote:
> >
> >
> >> User id mapping is an important consideration for me.
> >
> >
> > Some mapping has to be present somewhere already. Even very old git commits 
> > point at the right people. Perhaps it's based on e-mail addresses or 
> > something?
> >
> > https://github.com/apache/lucene/commit/5a2615650e104c0713407637d65ae0ce7c2b257a
> >
> > When the user isn't available, github just shows the nick, without the link.
> >
> > https://github.com/apache/lucene/commit/89a554ffab239c0118ccd454d76cdf714d793911
> >
> > Maybe infra could help with how it's done already for git integration.
> >
> > Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Plan for GitHub issue metadata management

[Tomoko Uchida]

I haven't used the "project" feature either - maybe it could be an
option but I can't have an opinion on it. Is there anyone who has
experience with it and wants to lead us to use it?

Tomoko

2022年6月20日(月) 18:59 Jens Wille :
>
> Hi,
>
> I'm just a bystander here. But are you aware that the new projects (beta)
> includes support for custom fields?
>
> 
>
> I haven't used them myself yet, but it seems that they might be a viable
> alternative to modeling everything with labels (which is more of a crutch I
> suppose).
>
> Cheers,
> Jens
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Plan for GitHub issue metadata management

[Tomoko Uchida]

Indeed versions are the most important metadata; I'd like to hear the
thoughts of others.

1. Fix Version(s)

We have only two options: Milestone or Label. One important difference
between them is that an issue can have only one milestone but multiple
labels. The other difference would be that while Milestone is special
metadata, labels are just flexible text tags for searching. I'm
personally fine with Milestone and my reasoning is that - we don't
release a bug fix or improvement in multiple versions anyway. We don't
have two CHANGES entries for one issue; if we resolve an issue in
"10.0.0" and "9.3.0" the CHANGES entry appears only in Lucene 9.3.0's
section.
However I don't have a strong opinion on it and go with others'
suggestions - should we continue to support multiple "fixed versions"
with labels (tags)?

2. Affects Version(s)

I have never used this metadata field but I'm perfectly fine with
supporting this with labels if we need it.

Tomoko

2022年6月20日(月) 18:40 Shai Erera :
>
> Can we support "Affects Versions" with a label too? "affectsVersion: 8.x"?
>
> Regarding Fix Versions, don't we have multiple of these sometimes? E.g. a bug 
> fix may go into "8.1", "9.x" and "main"? Is it OK if we just drop support for 
> this?
>
> On Mon, Jun 20, 2022 at 12:33 PM Tomoko Uchida  
> wrote:
>>
>> Hello all.
>>
>> Besides whether the migration of existing issues should be done or not
>> (we still do not reach an agreement on it), I started to play around
>> with GitHub issue metadata with a test repository.
>>
>> The current migration plan in my mind:
>>
>> * Issue Type -> Supported with labels (e.g. "type:bug"); it also can
>> be attached when opening issues with issue templates.
>> * Issue Priority -> Not supported.
>> * Affects Versions -> Not supported.
>> * Components -> Supported with labels (e.g.: "module:core").
>> * Resolution -> Not supported.
>> * Fix Version(s) -> Partially supported with Milestone; an issue can
>> have only one milestone - I'm fine with it.
>>
>> As you may see I'm going to drop the most of metadata that is
>> supported in Jira for the sake of brevity. If you have objections or
>> other perspectives, could you please speak up.
>>
>> Tomoko
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Plan for GitHub issue metadata management

[Tomoko Uchida]

Hello all.

Besides whether the migration of existing issues should be done or not
(we still do not reach an agreement on it), I started to play around
with GitHub issue metadata with a test repository.

The current migration plan in my mind:

* Issue Type -> Supported with labels (e.g. "type:bug"); it also can
be attached when opening issues with issue templates.
* Issue Priority -> Not supported.
* Affects Versions -> Not supported.
* Components -> Supported with labels (e.g.: "module:core").
* Resolution -> Not supported.
* Fix Version(s) -> Partially supported with Milestone; an issue can
have only one milestone - I'm fine with it.

As you may see I'm going to drop the most of metadata that is
supported in Jira for the sake of brevity. If you have objections or
other perspectives, could you please speak up.

Tomoko

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

Thanks Robert and Jan, for your information.

> I'm still against duplicating jira history over to GitHub. I think it will be 
> a confusing mess and not worth the effort.

I am against it to have duplicated issue history in two issue systems
too. I think it's a kind of my duty to provide information on what
can/cannot be done on it not to be stuck on an argument without basis.

Will you all please hold the discussion on whether we "should" migrate
existing issues or not for a little while.
I'll try to give a working example - let's see how it looks, then make
the final decision.

Tomoko

2022年6月19日(日) 7:25 Jan Høydahl :
>
> You'll not be able to create a GH issue with a script, on behalf of the 
> original reporter.
> Neither will you be able to add a GH issue comment impersonating the person 
> who made the JIRA comment.
> Rather, all issues and all comments would be made by the script/bot user, and 
> you'd have to add in free-text information about reporter and commenter.
> You may be able to assign an issue to the github-id of the original JIRA 
> assignee though.
>
> See 
> https://stackoverflow.com/questions/36540508/github-api-possible-to-set-reporter-of-issue-to-another-user-when-creating-issu
>
> I'm still against duplicating jira history over to GitHub. I think it will be 
> a confusing mess and not worth the effort. The history split can be mitigated 
> by documentation, and perhaps a search engine :)
>
> If, however, experiments show that a quality migration is possible, then can 
> we please open a separate git repo only for the historic issues? It is easy 
> to search across two repos in GitHub, e.g. 
> https://github.com/pulls?q=is%3Apr+is%3Aclosed+repo%3Aapache%2Flucene+repo%3Aapache%2Flucene-solr+wizard+
>
> Jan
>
> 18. jun. 2022 kl. 21:48 skrev Robert Muir :
>
>
>
> On Sat, Jun 18, 2022, 7:42 AM Tomoko Uchida  
> wrote:
>>
>> User id mapping is an important consideration for me.
>>
>> Can we find a mapping from Jira user id to GitHub account anywhere?
>
>
> I think we would have to create it. But my hope would be that maybe 50-100 
> names would cover large majority of issues.
>>
>> Don't we have to gain the consent of each individual to map both accounts?
>
>
> No, we don't have to ask permission to mention someone with an @username
>
>>
>> 2022年6月18日(土) 18:52 Robert Muir :
>> >
>> > I looked at some related projects on github:
>> > https://github.com/Skraeda/jira-2-github
>> > Does the barebones basics but helps you think of the inputs: "username
>> > mapping", "release -> milestone mapping", etc. Of course for a
>> > username mapping, maybe its best to just handle the top 99% or so and
>> > let the long-tail just come across as "full name". I also find plenty
>> > of projects that convert "special jira language" to markdown, e.g.
>> > https://github.com/catcombo/jira2markdown
>> > I'm not convinced conversion would be degraded, with a little bit of
>> > thought into the conversion, I think it could actually be *better*.
>> > github issues can do everything jira can, just without the fussy UI.
>> > e.g. issues can have attachments (for all the patch files), and
>> > attachment names can have duplicates. Issues can link to other issues,
>> > commits, or PRs easily.
>> >
>> > It just depends on how much we want to invest into it. If we want to
>> > really go whole-hog, then when we do the initial JIRA->issue
>> > conversion, we should *save that mapping* as a .CSV file or similar.
>> > Because later we could then use it to find/replace URLs in
>> > Changes.txt, source code, benchmark annotations, etc etc. Let's at
>> > least leave the possibility open to do that work as followup.
>> >
>> > I find the idea that we're stuck looking at JIRA forever ridiculous.
>> >
>> > On Sat, Jun 18, 2022 at 3:19 AM Dawid Weiss  wrote:
>> > >
>> > >
>> > > I honestly don't know what can be done and what has to be sacrificed. 
>> > > I'm pretty sure it'll be more difficult than svn->git conversion because 
>> > > more factors are involved. One tough thing to somehow preserve may be 
>> > > user names (reporters, etc.). I'm not sure how other projects dealt with 
>> > > that.
>> > >
>> > > Perhaps a way to do it incrementally would be to create a json/xml 
>> > > (structured) dump of jira content and then write a converter into a 
>> > > similar json/xml dump for importing into github. I remember it took many 
>> 

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

User id mapping is an important consideration for me.

Can we find a mapping from Jira user id to GitHub account anywhere?
Don't we have to gain the consent of each individual to map both accounts?

2022年6月18日(土) 18:52 Robert Muir :
>
> I looked at some related projects on github:
> https://github.com/Skraeda/jira-2-github
> Does the barebones basics but helps you think of the inputs: "username
> mapping", "release -> milestone mapping", etc. Of course for a
> username mapping, maybe its best to just handle the top 99% or so and
> let the long-tail just come across as "full name". I also find plenty
> of projects that convert "special jira language" to markdown, e.g.
> https://github.com/catcombo/jira2markdown
> I'm not convinced conversion would be degraded, with a little bit of
> thought into the conversion, I think it could actually be *better*.
> github issues can do everything jira can, just without the fussy UI.
> e.g. issues can have attachments (for all the patch files), and
> attachment names can have duplicates. Issues can link to other issues,
> commits, or PRs easily.
>
> It just depends on how much we want to invest into it. If we want to
> really go whole-hog, then when we do the initial JIRA->issue
> conversion, we should *save that mapping* as a .CSV file or similar.
> Because later we could then use it to find/replace URLs in
> Changes.txt, source code, benchmark annotations, etc etc. Let's at
> least leave the possibility open to do that work as followup.
>
> I find the idea that we're stuck looking at JIRA forever ridiculous.
>
> On Sat, Jun 18, 2022 at 3:19 AM Dawid Weiss  wrote:
> >
> >
> > I honestly don't know what can be done and what has to be sacrificed. I'm 
> > pretty sure it'll be more difficult than svn->git conversion because more 
> > factors are involved. One tough thing to somehow preserve may be user names 
> > (reporters, etc.). I'm not sure how other projects dealt with that.
> >
> > Perhaps a way to do it incrementally would be to create a json/xml 
> > (structured) dump of jira content and then write a converter into a similar 
> > json/xml dump for importing into github. I remember it took many iterations 
> > and trial and error for svn->git conversion to eventually reach the final 
> > shape and it was simpler  and faster to do it locally.
> >
> > Dawid
> >
> > On Sat, Jun 18, 2022 at 8:59 AM Tomoko Uchida 
> >  wrote:
> >>
> >> I'll give it a try though, I'm really skeptical that it can be done
> >> with a satisfactory level of quality (we want to "preserve" issue
> >> history, not just to have shallow/degraded copies, right?), and the
> >> migration will be significantly delayed to figure out the way to
> >> properly moving all issues to GitHub.
> >> if there is another way to bypass this challenge - please let me know.
> >>
> >> Tomoko
> >>
> >> 2022年6月18日(土) 15:44 Dawid Weiss :
> >>
> >> >
> >> >
> >> > Hi Tomoko,
> >> >
> >> > I've added a few bullet points that script could/should handle under 
> >> > LUCENE-10557, hope you don't mind. If you place these script(s) in the 
> >> > open then perhaps indeed we could try to collaborate and see what can be 
> >> > done.
> >> >
> >> > Dawid
> >> >
> >> > On Sat, Jun 18, 2022 at 5:33 AM Tomoko Uchida 
> >> >  wrote:
> >> >>
> >> >> Replying to myself - Jira issues can be read via REST API without any
> >> >> access token and we can iterate all issues by issue number.
> >> >> curl -s 
> >> >> https://issues.apache.org/jira/rest/api/latest/issue/LUCENE-10557
> >> >>
> >> >> Would you please hold the discussion for a while - it's a waste of our
> >> >> time without a working prototype to me. I will be back here with a
> >> >> sandbox github repo where part of existing jira issues are migrated
> >> >> (with the best effort).
> >> >> In the process, we could simultaneously figure out the way to operate
> >> >> GitHub metadata (milestones/labels).
> >> >>
> >> >> Tomoko
> >> >>
> >> >> 2022年6月18日(土) 10:41 Tomoko Uchida :
> >> >>
> >> >> >
> >> >> > Does anyone have information on API access keys to Jira (preferably,
> >> >> > read-only and limited to Lucene project)?
> >> >> > https://issues.apache.or

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

I'll give it a try though, I'm really skeptical that it can be done
with a satisfactory level of quality (we want to "preserve" issue
history, not just to have shallow/degraded copies, right?), and the
migration will be significantly delayed to figure out the way to
properly moving all issues to GitHub.
if there is another way to bypass this challenge - please let me know.

Tomoko

2022年6月18日(土) 15:44 Dawid Weiss :

>
>
> Hi Tomoko,
>
> I've added a few bullet points that script could/should handle under 
> LUCENE-10557, hope you don't mind. If you place these script(s) in the open 
> then perhaps indeed we could try to collaborate and see what can be done.
>
> Dawid
>
> On Sat, Jun 18, 2022 at 5:33 AM Tomoko Uchida  
> wrote:
>>
>> Replying to myself - Jira issues can be read via REST API without any
>> access token and we can iterate all issues by issue number.
>> curl -s https://issues.apache.org/jira/rest/api/latest/issue/LUCENE-10557
>>
>> Would you please hold the discussion for a while - it's a waste of our
>> time without a working prototype to me. I will be back here with a
>> sandbox github repo where part of existing jira issues are migrated
>> (with the best effort).
>> In the process, we could simultaneously figure out the way to operate
>> GitHub metadata (milestones/labels).
>>
>> Tomoko
>>
>> 2022年6月18日(土) 10:41 Tomoko Uchida :
>>
>> >
>> > Does anyone have information on API access keys to Jira (preferably,
>> > read-only and limited to Lucene project)?
>> > https://issues.apache.org/jira/browse/LUCENE-10622
>> >
>> > 2022年6月18日(土) 10:11 Tomoko Uchida :
>> > >
>> > > I feel like we should delay the decision on the mingration of existing
>> > > issues until we have a clear image of what can be done and what cannot
>> > > be done.
>> > >
>> > > I'll write some migration script that preserves the issue history as
>> > > far as possible - then come back here with some experience.
>> > > Let's make a decision upon the concrete knowledge and information.
>> > >
>> > > Tomoko
>> > >
>> > > 2022年6月18日(土) 9:26 Tomoko Uchida :
>> > > >
>> > > > I don't intend to neglect histories in Jira... it's an important,
>> > > > valuable asset for all of us and possible contributors in the future.
>> > > >
>> > > > It's important, *therefore*, I don't want to have the degraded copies
>> > > > of them on GitHub.
>> > > > We cannot preserve all of history - again, there should be tons of
>> > > > unignorable information losses (timestamp, reporter, assignee,
>> > > > markdown, metadata that cannot be ported to GitHub) if we attempt to
>> > > > migrate the whole Jira history into Github. Rather than trying to have
>> > > > such incomplete copies, I would preserve Jira issues in the perfectly
>> > > > archived status, then simply refer to them.
>> > > >
>> > > > Tomoko
>> > > >
>> > > > 2022年6月18日(土) 7:47 Gus Heck :
>> > > > >
>> > > > > I hope you count me as someone who sees history as important. It's 
>> > > > > important in more ways than one however. You gave the example of 
>> > > > > trying to understand something, and looking at the issue history 
>> > > > > directly. I also give weight to the scenario where someone has 
>> > > > > written a blog post about the topic and linked the issue "For the 
>> > > > > latest see LUCENE-" for example... Or someone planning upgrades 
>> > > > > has a spreadsheet of things to track down... The existing links 
>> > > > > should point to a *complete* history of the issue.
>> > > > >
>> > > > > I don't see the migration of everything to github as being as 
>> > > > > critical as you do but I'm not at all against migrating things that 
>> > > > > are closed if someone wants to do that work, and perhaps even 
>> > > > > copying over existing open issues periodically as they become closed 
>> > > > > (and accelerating the close rate by aggressive closing of silent 
>> > > > > issues). No new issues in Jira sounds fine, even better if enforced 
>> > > > > by Jira. Proceed from here in Github since that's where the 
>> > > > > community wants to go. Links to the migrated 

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

Replying to myself - Jira issues can be read via REST API without any
access token and we can iterate all issues by issue number.
curl -s https://issues.apache.org/jira/rest/api/latest/issue/LUCENE-10557

Would you please hold the discussion for a while - it's a waste of our
time without a working prototype to me. I will be back here with a
sandbox github repo where part of existing jira issues are migrated
(with the best effort).
In the process, we could simultaneously figure out the way to operate
GitHub metadata (milestones/labels).

Tomoko

2022年6月18日(土) 10:41 Tomoko Uchida :

>
> Does anyone have information on API access keys to Jira (preferably,
> read-only and limited to Lucene project)?
> https://issues.apache.org/jira/browse/LUCENE-10622
>
> 2022年6月18日(土) 10:11 Tomoko Uchida :
> >
> > I feel like we should delay the decision on the mingration of existing
> > issues until we have a clear image of what can be done and what cannot
> > be done.
> >
> > I'll write some migration script that preserves the issue history as
> > far as possible - then come back here with some experience.
> > Let's make a decision upon the concrete knowledge and information.
> >
> > Tomoko
> >
> > 2022年6月18日(土) 9:26 Tomoko Uchida :
> > >
> > > I don't intend to neglect histories in Jira... it's an important,
> > > valuable asset for all of us and possible contributors in the future.
> > >
> > > It's important, *therefore*, I don't want to have the degraded copies
> > > of them on GitHub.
> > > We cannot preserve all of history - again, there should be tons of
> > > unignorable information losses (timestamp, reporter, assignee,
> > > markdown, metadata that cannot be ported to GitHub) if we attempt to
> > > migrate the whole Jira history into Github. Rather than trying to have
> > > such incomplete copies, I would preserve Jira issues in the perfectly
> > > archived status, then simply refer to them.
> > >
> > > Tomoko
> > >
> > > 2022年6月18日(土) 7:47 Gus Heck :
> > > >
> > > > I hope you count me as someone who sees history as important. It's 
> > > > important in more ways than one however. You gave the example of trying 
> > > > to understand something, and looking at the issue history directly. I 
> > > > also give weight to the scenario where someone has written a blog post 
> > > > about the topic and linked the issue "For the latest see LUCENE-" 
> > > > for example... Or someone planning upgrades has a spreadsheet of things 
> > > > to track down... The existing links should point to a *complete* 
> > > > history of the issue.
> > > >
> > > > I don't see the migration of everything to github as being as critical 
> > > > as you do but I'm not at all against migrating things that are closed 
> > > > if someone wants to do that work, and perhaps even copying over 
> > > > existing open issues periodically as they become closed (and 
> > > > accelerating the close rate by aggressive closing of silent issues). No 
> > > > new issues in Jira sounds fine, even better if enforced by Jira. 
> > > > Proceed from here in Github since that's where the community wants to 
> > > > go. Links to the migrated version automatically added to Jira and/or 
> > > > backlinks to Jira would be just fine too since readers might (hopefully 
> > > > needlessly) worry that something didn't get migrated, we should make it 
> > > > easy to check.
> > > >
> > > > What I don't want is for someone to land on an issue via link or via 
> > > > google search (or via search in jira because they are using Jira 
> > > > already for some other apache project), read through it and think A) it 
> > > > never got resolved when it did or B) miss the fact that it got reopened 
> > > > and further changes were made and only have half the story... or any 
> > > > other scenario where they are looking at an incomplete record of the 
> > > > issue. (thus obfuscating/splitting the very important rich history 
> > > > across systems).
> > > >
> > > > So that's why I feel issues should be completely tracked in the system 
> > > > where they were created. Syncing old closed stuff into a new system 
> > > > probably is fine so long as there are periodic sweeps to pull in 
> > > > reopens or newly completed issues. We could even sync open things so 
> > > > long as they are clearly marked in the title a

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

Does anyone have information on API access keys to Jira (preferably,
read-only and limited to Lucene project)?
https://issues.apache.org/jira/browse/LUCENE-10622

2022年6月18日(土) 10:11 Tomoko Uchida :
>
> I feel like we should delay the decision on the mingration of existing
> issues until we have a clear image of what can be done and what cannot
> be done.
>
> I'll write some migration script that preserves the issue history as
> far as possible - then come back here with some experience.
> Let's make a decision upon the concrete knowledge and information.
>
> Tomoko
>
> 2022年6月18日(土) 9:26 Tomoko Uchida :
> >
> > I don't intend to neglect histories in Jira... it's an important,
> > valuable asset for all of us and possible contributors in the future.
> >
> > It's important, *therefore*, I don't want to have the degraded copies
> > of them on GitHub.
> > We cannot preserve all of history - again, there should be tons of
> > unignorable information losses (timestamp, reporter, assignee,
> > markdown, metadata that cannot be ported to GitHub) if we attempt to
> > migrate the whole Jira history into Github. Rather than trying to have
> > such incomplete copies, I would preserve Jira issues in the perfectly
> > archived status, then simply refer to them.
> >
> > Tomoko
> >
> > 2022年6月18日(土) 7:47 Gus Heck :
> > >
> > > I hope you count me as someone who sees history as important. It's 
> > > important in more ways than one however. You gave the example of trying 
> > > to understand something, and looking at the issue history directly. I 
> > > also give weight to the scenario where someone has written a blog post 
> > > about the topic and linked the issue "For the latest see LUCENE-" for 
> > > example... Or someone planning upgrades has a spreadsheet of things to 
> > > track down... The existing links should point to a *complete* history of 
> > > the issue.
> > >
> > > I don't see the migration of everything to github as being as critical as 
> > > you do but I'm not at all against migrating things that are closed if 
> > > someone wants to do that work, and perhaps even copying over existing 
> > > open issues periodically as they become closed (and accelerating the 
> > > close rate by aggressive closing of silent issues). No new issues in Jira 
> > > sounds fine, even better if enforced by Jira. Proceed from here in Github 
> > > since that's where the community wants to go. Links to the migrated 
> > > version automatically added to Jira and/or backlinks to Jira would be 
> > > just fine too since readers might (hopefully needlessly) worry that 
> > > something didn't get migrated, we should make it easy to check.
> > >
> > > What I don't want is for someone to land on an issue via link or via 
> > > google search (or via search in jira because they are using Jira already 
> > > for some other apache project), read through it and think A) it never got 
> > > resolved when it did or B) miss the fact that it got reopened and further 
> > > changes were made and only have half the story... or any other scenario 
> > > where they are looking at an incomplete record of the issue. (thus 
> > > obfuscating/splitting the very important rich history across systems).
> > >
> > > So that's why I feel issues should be completely tracked in the system 
> > > where they were created. Syncing old closed stuff into a new system 
> > > probably is fine so long as there are periodic sweeps to pull in reopens 
> > > or newly completed issues. We could even sync open things so long as they 
> > > are clearly marked in the title as having their primary record in Jira 
> > > and "last synced from JIRA on -MM-DD" or something in a final comment 
> > > each time new content is brought over.
> > >
> > > For simplicity and workload however maybe just sync things when they 
> > > close. Depends on how much effort the person writing code for syncing 
> > > things wants to put into it I guess.
> > >
> > > Although I agree with Dawid on the "What if Elon buys it?" issue, that 
> > > ship has sailed, the community accepts that risk and we probably should 
> > > not rehash it.
> > >
> > > WRT Robert's comments on PRs being issues... this has already worried me 
> > > because I've already seen a lot of discussion on PR's and I've worried 
> > > that this stuff has the potential to get lost or be hard to find. If 
> > > there is one key

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

I feel like we should delay the decision on the mingration of existing
issues until we have a clear image of what can be done and what cannot
be done.

I'll write some migration script that preserves the issue history as
far as possible - then come back here with some experience.
Let's make a decision upon the concrete knowledge and information.

Tomoko

2022年6月18日(土) 9:26 Tomoko Uchida :
>
> I don't intend to neglect histories in Jira... it's an important,
> valuable asset for all of us and possible contributors in the future.
>
> It's important, *therefore*, I don't want to have the degraded copies
> of them on GitHub.
> We cannot preserve all of history - again, there should be tons of
> unignorable information losses (timestamp, reporter, assignee,
> markdown, metadata that cannot be ported to GitHub) if we attempt to
> migrate the whole Jira history into Github. Rather than trying to have
> such incomplete copies, I would preserve Jira issues in the perfectly
> archived status, then simply refer to them.
>
> Tomoko
>
> 2022年6月18日(土) 7:47 Gus Heck :
> >
> > I hope you count me as someone who sees history as important. It's 
> > important in more ways than one however. You gave the example of trying to 
> > understand something, and looking at the issue history directly. I also 
> > give weight to the scenario where someone has written a blog post about the 
> > topic and linked the issue "For the latest see LUCENE-" for example... 
> > Or someone planning upgrades has a spreadsheet of things to track down... 
> > The existing links should point to a *complete* history of the issue.
> >
> > I don't see the migration of everything to github as being as critical as 
> > you do but I'm not at all against migrating things that are closed if 
> > someone wants to do that work, and perhaps even copying over existing open 
> > issues periodically as they become closed (and accelerating the close rate 
> > by aggressive closing of silent issues). No new issues in Jira sounds fine, 
> > even better if enforced by Jira. Proceed from here in Github since that's 
> > where the community wants to go. Links to the migrated version 
> > automatically added to Jira and/or backlinks to Jira would be just fine too 
> > since readers might (hopefully needlessly) worry that something didn't get 
> > migrated, we should make it easy to check.
> >
> > What I don't want is for someone to land on an issue via link or via google 
> > search (or via search in jira because they are using Jira already for some 
> > other apache project), read through it and think A) it never got resolved 
> > when it did or B) miss the fact that it got reopened and further changes 
> > were made and only have half the story... or any other scenario where they 
> > are looking at an incomplete record of the issue. (thus 
> > obfuscating/splitting the very important rich history across systems).
> >
> > So that's why I feel issues should be completely tracked in the system 
> > where they were created. Syncing old closed stuff into a new system 
> > probably is fine so long as there are periodic sweeps to pull in reopens or 
> > newly completed issues. We could even sync open things so long as they are 
> > clearly marked in the title as having their primary record in Jira and 
> > "last synced from JIRA on -MM-DD" or something in a final comment each 
> > time new content is brought over.
> >
> > For simplicity and workload however maybe just sync things when they close. 
> > Depends on how much effort the person writing code for syncing things wants 
> > to put into it I guess.
> >
> > Although I agree with Dawid on the "What if Elon buys it?" issue, that ship 
> > has sailed, the community accepts that risk and we probably should not 
> > rehash it.
> >
> > WRT Robert's comments on PRs being issues... this has already worried me 
> > because I've already seen a lot of discussion on PR's and I've worried that 
> > this stuff has the potential to get lost or be hard to find. If there is 
> > one key positive of this move is that they will become easier to find since 
> > the search in github can find it. I would say that a PR is not a substitute 
> > for a well described issue report but that's probably a separate discussion 
> > (which I would hope mirrors the policy on small edits like typos or adding 
> > comments/javadoc not needing an issue). I've also seen folks who like to 
> > clean up and remove old branches and PR's, which is problematic if that's 
> > where the important discussion is (possibly a 3rd can of worms there).
> &g

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

I don't intend to neglect histories in Jira... it's an important,
valuable asset for all of us and possible contributors in the future.

It's important, *therefore*, I don't want to have the degraded copies
of them on GitHub.
We cannot preserve all of history - again, there should be tons of
unignorable information losses (timestamp, reporter, assignee,
markdown, metadata that cannot be ported to GitHub) if we attempt to
migrate the whole Jira history into Github. Rather than trying to have
such incomplete copies, I would preserve Jira issues in the perfectly
archived status, then simply refer to them.

Tomoko

2022年6月18日(土) 7:47 Gus Heck :
>
> I hope you count me as someone who sees history as important. It's important 
> in more ways than one however. You gave the example of trying to understand 
> something, and looking at the issue history directly. I also give weight to 
> the scenario where someone has written a blog post about the topic and linked 
> the issue "For the latest see LUCENE-" for example... Or someone planning 
> upgrades has a spreadsheet of things to track down... The existing links 
> should point to a *complete* history of the issue.
>
> I don't see the migration of everything to github as being as critical as you 
> do but I'm not at all against migrating things that are closed if someone 
> wants to do that work, and perhaps even copying over existing open issues 
> periodically as they become closed (and accelerating the close rate by 
> aggressive closing of silent issues). No new issues in Jira sounds fine, even 
> better if enforced by Jira. Proceed from here in Github since that's where 
> the community wants to go. Links to the migrated version automatically added 
> to Jira and/or backlinks to Jira would be just fine too since readers might 
> (hopefully needlessly) worry that something didn't get migrated, we should 
> make it easy to check.
>
> What I don't want is for someone to land on an issue via link or via google 
> search (or via search in jira because they are using Jira already for some 
> other apache project), read through it and think A) it never got resolved 
> when it did or B) miss the fact that it got reopened and further changes were 
> made and only have half the story... or any other scenario where they are 
> looking at an incomplete record of the issue. (thus obfuscating/splitting the 
> very important rich history across systems).
>
> So that's why I feel issues should be completely tracked in the system where 
> they were created. Syncing old closed stuff into a new system probably is 
> fine so long as there are periodic sweeps to pull in reopens or newly 
> completed issues. We could even sync open things so long as they are clearly 
> marked in the title as having their primary record in Jira and "last synced 
> from JIRA on -MM-DD" or something in a final comment each time new 
> content is brought over.
>
> For simplicity and workload however maybe just sync things when they close. 
> Depends on how much effort the person writing code for syncing things wants 
> to put into it I guess.
>
> Although I agree with Dawid on the "What if Elon buys it?" issue, that ship 
> has sailed, the community accepts that risk and we probably should not rehash 
> it.
>
> WRT Robert's comments on PRs being issues... this has already worried me 
> because I've already seen a lot of discussion on PR's and I've worried that 
> this stuff has the potential to get lost or be hard to find. If there is one 
> key positive of this move is that they will become easier to find since the 
> search in github can find it. I would say that a PR is not a substitute for a 
> well described issue report but that's probably a separate discussion (which 
> I would hope mirrors the policy on small edits like typos or adding 
> comments/javadoc not needing an issue). I've also seen folks who like to 
> clean up and remove old branches and PR's, which is problematic if that's 
> where the important discussion is (possibly a 3rd can of worms there).
>
> -Gus
>
> On Fri, Jun 17, 2022 at 4:34 PM Robert Muir  wrote:
>>
>> On Fri, Jun 17, 2022 at 3:27 PM Dawid Weiss  wrote:
>> >
>> > I'd be more afraid of what happens to github issues in two years (or 
>> > longer). Will it look the same? Will it be different? Will it be gone (and 
>> > how do we get a backup of the isse history then)? Contrary to the 
>> > apache-hosted Jira, github is very much an independent entity. If Elon 
>> > Musk decides to buy and close it tomorrow... then what? :)
>> >
>>
>> We already have a ton of github "issues" (pull requests, since PRs are 
>> issues).
>> If you want to "back them up", its easy, you can paginate thru them
>> 100 at a time, e.g. run this command, incrementing 'page' until it
>> returns empty list:
>>
>>   curl -H "Accept: application/vnd.github.v3+json"
>> "https://api.github.com/repos/apache/lucene/issues?per_page=100=1=asc=all;
>> > file1.json
>>
>> Yeah of course if you want to 

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

> I see you already have a start at the migration plan, yay!  (The comment on 
> LUCENE-10557)
> Could we maybe pull that out into a wiki page so we can more easily 
> collaborate on the steps?

There would not be so many topics that are controversial except for
the current discussion about existing Jira issues, and I think we are
close to reaching a conclusion.
I re-summarized the migration steps and tasks to be done in the issue
description and I will update it when there is progress. (Most of the
remaining work is an administrative job.)

Tomoko

2022年6月16日(木) 17:13 Dawid Weiss :
>
>
> Hi Tomoko,
>
>>
>> * All new issues should be opened on GitHub. Opening new Jira issues
>> is discouraged unless there is a good reason.
>
>
> I'm fine with this. New issues from contributors who are not aware of the 
> migration can be immediately
> cloned to github and closed in Jira as well (vide Adrien's previous 
> suggestion to make an explicit template in
> Jira to point people in the right direction). The "discouragement" would then 
> probably apply only to those folks who
> expressed their negative sentiments against github (and don't have an account 
> there, for example).
>
>>
>> * All existing issues should be resolved in Jira. Copying or moving
>> Jira issues to GitHub is discouraged unless there is a good reason.
>
>
> I'm also fine with this. Again - allows for a gradual transition without 
> extra effort for you. My experience tells me such
> transition will be a pretty rapid process anyway. If you take a look at how 
> fast it was to switch to pull requests vs.
> patch-in-jira, it's likely to follow the same kind of pattern.
>
> Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

We have two conflicting requests:
1. We don't want to duplicate/diverge issues; an issue's identity is
what matters the most.
2. We don't want to keep holding multiple issue systems; having only
one system is what matters the most.

They are inevitably in conflict with each other - it looks like many
folks put more weight on 1 than 2, then I would go with it.
I'd like to set a principle (not a very strict rule) to avoid
unnecessary confusion during the migration period.

* All new issues should be opened on GitHub. Opening new Jira issues
is discouraged unless there is a good reason.
* All existing issues should be resolved in Jira. Copying or moving
Jira issues to GitHub is discouraged unless there is a good reason.

Is there anyone who strongly opposes this?

Tomoko

2022年6月16日(木) 5:44 David Smiley :
>
> I'm not a fan of the automated copying of any issues into GitHub, which will 
> create a divergence / duplicity of an issue's identity.  It will only be a 
> relatively temporary annoyance to have two systems to "work" on an issue.  
> Eventually, JIRA will only be historical; let's say Lucene 11.  At that point 
> if there's an older issue of resumed interest, which would be getting 
> increasingly rare, someone could manually copy the original description and 
> title into GitHub plus a historical reference back.  Again -- rare by then.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Jun 15, 2022 at 4:18 PM Tomoko Uchida  
> wrote:
>>
>> It looks like we talked about two or three things at the same time -
>> and I'm afraid the discussion will quickly turn into a disordered
>> state and I won't be able to track it.
>>
>> Let me decide one thing: Let's NOT try to move histories to GitHub.
>> Closed issues will remain in Jira forever and we can refer to them
>> anytime from anywhere. I think I said that before several times.
>>
>> I would like to focus on the future here - can we make a decision on
>> how to handle active (unresolved) issues and issues that will be
>> opened in the future.
>>
>> Thank you,
>> Tomoko
>>
>> 2022年6月16日(木) 4:18 Dawid Weiss :
>>
>> >
>> >
>> >> Totally agree. The history of closed issues answer “when did this change 
>> >> and why?”. Migrate them all. Computers can do that. It avoids asking 
>> >> humans to think about where stuff is.
>> >
>> >
>> > We do have different views of that. To me, the history is preserved 
>> > perfectly well in Jira, it's not being phased out. Moving to github as the 
>> > issue tracking system is fine but different to me than code transitions 
>> > (cvs->svn->git). With code, you do have an existing state and history you 
>> > build from. With issue tickets - not so much. And even if you want to 
>> > create a ticket in the new system, you can easily link to the previous 
>> > one. It's the "web" of hyperlinks, right?
>> >
>> > I'm a bit afraid that moving hundreds of jira issues to github will have 
>> > the reverse effect - duplicate the same information but with quality 
>> > degraded, for example automatic links that work in Jira will no longer 
>> > work or point at the ported github issues ("this is related to LUCENE-xyz 
>> > or SOLR-abc, blah, blah blah.")?
>> >
>> > I don't want to stand in the way of progress but we've gone through a 
>> > similar transition at our company and I never had a problem using both 
>> > systems at the same time; jira just gradually atrophied into a read-only 
>> > state once issues in there got stale or resolved.
>> >
>> > Dawid
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

It looks like we talked about two or three things at the same time -
and I'm afraid the discussion will quickly turn into a disordered
state and I won't be able to track it.

Let me decide one thing: Let's NOT try to move histories to GitHub.
Closed issues will remain in Jira forever and we can refer to them
anytime from anywhere. I think I said that before several times.

I would like to focus on the future here - can we make a decision on
how to handle active (unresolved) issues and issues that will be
opened in the future.

Thank you,
Tomoko

2022年6月16日(木) 4:18 Dawid Weiss :

>
>
>> Totally agree. The history of closed issues answer “when did this change and 
>> why?”. Migrate them all. Computers can do that. It avoids asking humans to 
>> think about where stuff is.
>
>
> We do have different views of that. To me, the history is preserved perfectly 
> well in Jira, it's not being phased out. Moving to github as the issue 
> tracking system is fine but different to me than code transitions 
> (cvs->svn->git). With code, you do have an existing state and history you 
> build from. With issue tickets - not so much. And even if you want to create 
> a ticket in the new system, you can easily link to the previous one. It's the 
> "web" of hyperlinks, right?
>
> I'm a bit afraid that moving hundreds of jira issues to github will have the 
> reverse effect - duplicate the same information but with quality degraded, 
> for example automatic links that work in Jira will no longer work or point at 
> the ported github issues ("this is related to LUCENE-xyz or SOLR-abc, blah, 
> blah blah.")?
>
> I don't want to stand in the way of progress but we've gone through a similar 
> transition at our company and I never had a problem using both systems at the 
> same time; jira just gradually atrophied into a read-only state once issues 
> in there got stale or resolved.
>
> Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

I agree with we shouldn't make our issue system diverge and we have to
keep only one primary one.
It's very confusing to have two active issue systems for me (and also
for many of the devs I think), it will make the situation worse than
it is now.
Meanwhile, I didn't think we should make a hard, atomic switch - I
thought we can leave some space for using both GitHub and Jira, the
former is the primary and officially recommended, and the latter is
deprecated but still an option if there is a valid reason to choose
it.

There is no need to rush to reach a conclusion. I would like to keep
the conversation open until we can make a decision.

Tomoko

2022年6月16日(木) 0:56 Michael McCandless :

>
> On Wed, Jun 15, 2022 at 10:46 AM Tomoko Uchida  
> wrote:
>>
>> Thank you everyone for your suggestions.
>> I don't have a strong opinion on how to handle existing issues, I just
>> want to proceed with the migration smoothly. I'd open this discussion
>> until we find a better (not perfect) option or reach some level of
>> agreement.
>
>
> I see you already have a start at the migration plan, yay!  (The comment on 
> LUCENE-10557)
>
> Could we maybe pull that out into a wiki page so we can more easily 
> collaborate on the steps?
>
>>
>> > make the Jira project read only.
>>
>> I'm sorry but I don't think we can make Jira read only... I think we
>> should support the backup contribution paths outside GitHub, and
>> personally, I don't want to back to a mail-based way.
>> We've seen there are people who don't use GitHub for whatever reason
>> and I think we can't ignore the risk of GitHub account banning - it
>> can happen accidentally to anyone (I don't know the surveillance
>> system in GitHub at all but it might be automated? Systems can make
>> mistakes and recovering an account may take some time).
>
>
> Hmm, I think it's quite risky/dangerous to leave both writable?  It'd be 
> forking our issue tracker.  We'll have situations where some of us update the 
> Jira issue, others update the GitHub issue, we lose context/comments, we 
> duplicate work (thinking nobody is working on the GitHub issue yet someone 
> was actually working on the Jira one).  It would add risk/friction/taxation 
> to development going forward ... people would need to know to check two 
> places (GitHub and Jira) for updates, new issues, patches, linked PRs, etc.
>
> To me the migration would ideally be an atomic switch -- only Jira is 
> writeable up until some point, then it goes read only, we kick off the 
> (hopefully already well tested/debugged migration tool, probably just forking 
> this nice tool that the Lucene.net devs created), then GitHub issues is 
> writable.
>
> This nicely matches how SVN -> Git migration went.
>
> Yes, some people are not fully comfortable with GitHub, yet, but we expect 
> that to be the minority, we expect account blocking to be rare and easy to 
> resolve, etc. (since our VOTE to migrate has passed).
>
> I really feel we should make a hard switch for the best long-term health of 
> the dev community.
>
> Mike McCandless
>
> http://blog.mikemccandless.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

Thank you everyone for your suggestions.
I don't have a strong opinion on how to handle existing issues, I just
want to proceed with the migration smoothly. I'd open this discussion
until we find a better (not perfect) option or reach some level of
agreement.

> make the Jira project read only.

I'm sorry but I don't think we can make Jira read only... I think we
should support the backup contribution paths outside GitHub, and
personally, I don't want to back to a mail-based way.
We've seen there are people who don't use GitHub for whatever reason
and I think we can't ignore the risk of GitHub account banning - it
can happen accidentally to anyone (I don't know the surveillance
system in GitHub at all but it might be automated? Systems can make
mistakes and recovering an account may take some time).

Tomoko

2022年6月15日(水) 22:51 Michael McCandless :
>
> I would prefer that we migrate all issues to GitHub and then make the Jira 
> project read only.
>
> There is a rich history to our project in these issues that we should not 
> discard.  This is a unique property of Apache Lucene since our project has 
> been in existence and so vibrant for so much time.  Those who do not 
> know/study history are doomed to repeat it :)
>
> Expecting new developers to remember to "oh, long ago this project used this 
> old thing called Jira, you have to go search that, to find out why XYZ was 
> done this way in Lucene, pre-Github-issue-migration" is not a good solution 
> -- many won't remember (nor eventually, know) to do so.
>
> If I saw it correctly, at least two other projects (or maybe two people from 
> the same project, not sure) created a one-off tool to perform the migration 
> for their projects.  It isn't perfect of course (GitHub issues may not be 
> able to represent all metadata that Jira has), but we should migrate what is 
> possible.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Jun 15, 2022 at 9:34 AM Michael Sokolov  wrote:
>>
>> Agree with everyone here. Also consider that if we duplicate there
>> will be two copies of the same issue, and they will inevitably
>> diverge...
>>
>> On Wed, Jun 15, 2022 at 9:28 AM Jan Høydahl  wrote:
>> >
>> > +1 for a manual approach
>> >
>> > Over time the volume will gravitate to mostly GitHub issues. And JIRA will 
>> > always remain as an archive, so nothing is lost. Devs can always peek into 
>> > the list of open JIRAs any time and choose to start a PR for one. A slight 
>> > disadvantage is of course that in the first year or two you need to look 
>> > in both systems to get a full overview of all open issues. But auto 
>> > migrating hundreds of abandoned JIRA issues to GitHub is no better imo.
>> >
>> > Jan
>> >
>> > 15. jun. 2022 kl. 13:03 skrev Dawid Weiss :
>> >
>> >
>> >> Maybe a 3rd option could be to only use GitHub for new issues by adding 
>> >> some text to the Jira create issue dialog that says something like "JIRA 
>> >> is deprecated, please use GitHub for new issues" to encourage users to 
>> >> create new issues on GitHub instead of JIRA.
>> >
>> >
>> > I was thinking this too, actually. It'd allow for a more graceful 
>> > transition period from one system to another. It'd also help keep 
>> > cross-links (from comments, etc.) in the old issues reference proper 
>> > targets. And I don't see many disadvantages - I imagine that folks who 
>> > wish to revisit old(er) open Jira issues and prefer GH can close the jira 
>> > ticket as a duplicate and open a new corresponding GH issue. Wouldn't this 
>> > be easier (for you as well)? The key change would be procedural -- allow 
>> > pull requests and github issues as first-class "change" tickets.
>> >
>> > D.
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

Hi all,
there is one thing we need to decide for the migration.

I think we can migrate the whole issue in Jira (we have 10,000+ issues
in total) though, I am thinking of migrating only unresolved issues.
Already closed issues can remain Jira as history and can be
referred/searched when it's needed, I think.
I'm not going to screen issues by any criteria such as creation date -
can't estimate what issue is obsoleted or not.
If you have any suggestions on it, please let me know by replying to
this mail or leaving comments on the Jira.

It'll take some time for me so thank you for your patience.
Tomoko

2022年6月14日(火) 16:41 Tomoko Uchida :
>
> It's been >7d since the vote was initiated and the result is:
>
> +1  16  (12 binding)
> +0  3 (3 binding)
> -1  3 (3 binding)
>
> This vote has PASSED.
>
> Thanks to everyone who is involved in the discussion and/or voted.
> The work will continue on LUCENE-10557.
>
> Best,
> Tomoko

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[RESULT] [VOTE] Migration to GitHub issue from Jira

[Tomoko Uchida]

It's been >7d since the vote was initiated and the result is:

+1  16  (12 binding)
+0  3 (3 binding)
-1  3 (3 binding)

This vote has PASSED.

Thanks to everyone who is involved in the discussion and/or voted.
The work will continue on LUCENE-10557.

Best,
Tomoko

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene » Lucene-Check-main - Build # 5746 - Failure!

[Tomoko Uchida]

The gradle cache was cleaned up on the two Jenkins servers (nodes)
that run jobs of Lucene and Solr.
It looks like all jobs are getting back to normal after removing the
cache folder.
I'd schedule the cleaning up job to run periodically (once per week, maybe?).

Tomoko

2022年6月7日(火) 6:20 Tomoko Uchida :
>
> I don't think anyone ran the job to clean up the gradle cache today,
> and the job still fails with:
>
> A problem occurred evaluating root project 'lucene-root'.
> > Could not load compiled classes for script 
> > '/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Check-main/gradle/validation/validate-source-patterns.gradle'
> >  from cache.
>
> As a trial, I will manually run this job and see the results.
> https://ci-builds.apache.org/job/Lucene/job/Clean%20up%20Gradle%20cache/
>
> Tomoko
>
> 2022年6月7日(火) 3:56 Dawid Weiss :
> >
> >
> > Thanks for clarifying (and fixing) - Tomoko, Kevin. I'm not sure what's 
> > causing this either.
> >
> > Dawid
> >
> > On Mon, Jun 6, 2022 at 4:16 PM Kevin Risden  wrote:
> >>
> >> I created the 
> >> https://ci-builds.apache.org/job/Solr/job/lucene-solr-1-gradle-cache-cleanup
> >>  job since a similar error was seen a few months ago:
> >>
> >> https://lists.apache.org/thread/jor6ct8l2vpq7x98hxdfn8xnp0ln6xqj
> >>
> >> It did fix the problem, but was never able to identify the root cause.
> >>
> >> Kevin Risden
> >>
> >>
> >> On Mon, Jun 6, 2022 at 9:56 AM Tomoko Uchida 
> >>  wrote:
> >>>
> >>> I was able to log in to the ASF Jenkins Console and created this job
> >>> that just deletes the whole gradle cache folder on nodes that are
> >>> labeled "lucene" (please see the job configuration).
> >>> https://ci-builds.apache.org/job/Lucene/job/Clean%20up%20Gradle%20cache/
> >>>
> >>> I didn't set a schedule for the job and haven't executed it yet (it
> >>> may affect all running Lucene jobs) but I think I or anyone with an
> >>> ASF account can manually run it.
> >>>
> >>> 2022年6月6日(月) 15:18 Dawid Weiss :
> >>> >
> >>> >
> >>> > This seems like a gradle cache problem somehow:
> >>> >
> >>> > Could not load compiled classes for script 
> >>> > '/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Check-main/gradle/validation/validate-source-patterns.gradle'
> >>> >  from cache.
> >>> >
> >>> >
> >>> > I'm not sure how to fix it on those agent machines - I see a jenkins 
> >>> > job with this name:
> >>> >
> >>> >
> >>> > https://ci-builds.apache.org/job/Solr/job/lucene-solr-1-gradle-cache-cleanup
> >>> >
> >>> >
> >>> > But this is disabled... Has anybody experienced this before (whoever 
> >>> > created that job)?
> >>> >
> >>> >
> >>> > Dawid
> >>> >
> >>> >
> >>> > On Mon, Jun 6, 2022 at 6:54 AM Apache Jenkins Server 
> >>> >  wrote:
> >>> >>
> >>> >> Build: 
> >>> >> https://ci-builds.apache.org/job/Lucene/job/Lucene-Check-main/5746/
> >>> >>
> >>> >> No tests ran.
> >>> >>
> >>> >> Build Log:
> >>> >> [...truncated 73 lines...]
> >>> >> BUILD FAILED in 12s
> >>> >> 2 actionable tasks: 2 executed
> >>> >> Build step 'Invoke Gradle script' changed build result to FAILURE
> >>> >> Build step 'Invoke Gradle script' marked build as failure
> >>> >> Archiving artifacts
> >>> >> Recording test results
> >>> >> ERROR: Step ‘Publish JUnit test result report’ failed: No test report 
> >>> >> files were found. Configuration error?
> >>> >> Email was triggered for: Failure - Any
> >>> >> Sending email for trigger: Failure - Any
> >>> >>
> >>> >> -
> >>> >> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
> >>> >> For additional commands, e-mail: builds-h...@lucene.apache.org
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Migration to GitHub issue from Jira (LUCENE-10557)

[Tomoko Uchida]

I'm sorry there was a mistake in the important date. This is the
corrected version.

==
this vote received 13 ballots in total (including +1, +0, and -1) so
far, this does not reach the quorum of 15. I'll extend the term to
2022-06-13 16:00 UTC.

This is a friendly reminder note in case you have missed it in my first post.

*IMPORTANT NOTE*
I set a local protocol for this vote.
There are 95 committers on this project [3] - the vote will be
effective if it successfully gains more than 15% of voters (>= 15)
from committers (including PMC members). This means, that although
only PMC member votes are counted for the final result, the votes from
all committers are important to make the vote result effective.

If there are less than 15 votes at 2022-06-06 16:00 UTC, I will expand
the term to 2022-06-13 16:00 UTC. If this fails to get sufficient
voters after the expanded time limit, I'll cancel this vote regardless
of the result.

Thanks,
Tomoko

2022年6月7日(火) 12:03 Tomoko Uchida :
>
> Hi all,
> this vote received 13 ballots in total (including +1, +0, and -1) so
> far, this does not reach the quorum of 15. I'll extend the term to
> 2022-06-06 16:00 UTC.
>
> This is a friendly reminder note in case you have missed it in my first post.
>
> *IMPORTANT NOTE*
> I set a local protocol for this vote.
> There are 95 committers on this project [3] - the vote will be
> effective if it successfully gains more than 15% of voters (>= 15)
> from committers (including PMC members). This means, that although
> only PMC member votes are counted for the final result, the votes from
> all committers are important to make the vote result effective.
>
> If there are less than 15 votes at 2022-06-06 16:00 UTC, I will expand
> the term to 2022-06-13 16:00 UTC. If this fails to get sufficient
> voters after the expanded time limit, I'll cancel this vote regardless
> of the result.
>
> Thanks,
> Tomoko
>
> 2022年6月1日(水) 6:19 Alessandro Benedetti :
> >
> > +1(committer, non PMC)
> >
> > Lately I kinda feel having to create the Jira, after I detailed a 
> > contribution in the pull request, is just a boilerplate activity of copying 
> > and pasting and tagging again.
> > I would be happy to reduce this burden.
> > I left other details in the discussion thread.
> >
> > Cheers
> >
> >
> > On Tue, 31 May 2022, 21:19 Jason Gerlowski,  wrote:
> >>
> >> +1 (PMC)
> >>
> >> I understand concerns about handing governance over to a 3rd party, but 
> >> letting that drive our decision-making here feels like optimizing for a 
> >> rare case that might never occur.  I'd m,uch rather optimize for making 
> >> things easiest for contributors, and then accommodate any "Github ToS ban, 
> >> sanctions, etc." situations if and when they crop up on a case by case 
> >> basis.
> >>
> >> Best,
> >>
> >> Jason
> >>
> >> On Tue, May 31, 2022 at 10:09 AM Gus Heck  wrote:
> >>>
> >>> -1 I think the disruption and bifurcation of where to find history is not 
> >>> worth it. I also noticed a comment in the lucene issue for migration with 
> >>> summaries by date range, status, affects version,  etc. sub-area, exactly 
> >>> the sort of thing I expect to be much more difficult to obtain from 
> >>> github. What I would find interesting is a deep integration of the two 
> >>> systems so that initiation and basic commenting could be handled on 
> >>> github, but transmitted to Jira where full metadata and 
> >>> reporting/tracking could be maintained.
> >>>
> >>> On Tue, May 31, 2022 at 12:17 AM Ishan Chattopadhyaya 
> >>>  wrote:
> >>>>
> >>>> -1
> >>>>
> >>>> On Tue, 31 May, 2022, 4:06 am Xi Chen,  
> >>>> wrote:
> >>>>>
> >>>>> +1 from me (committer, non-PMC)
> >>>>>
> >>>>> Thanks Tomoko for starting the discussion and organizing / leading this 
> >>>>> effort!
> >>>>>
> >>>>> Best,
> >>>>> Zach
> >>>>>
> >>>>> On May 30, 2022, at 2:56 PM, Houston Putman  wrote:
> >>>>>
> >>>>> 
> >>>>> +1 Approve (PMC)
> >>>>>
> >>>>> Thanks so much for doing all of the work for this Tomoko!
> >>>>>
> >>>>> - Houston
> >>>>>
> >>>>> On Mon, May 30, 2022 at 5:38 PM David Smiley  wrote:
> >>>>>

Re: [VOTE] Migration to GitHub issue from Jira (LUCENE-10557)

[Tomoko Uchida]

Hi all,
this vote received 13 ballots in total (including +1, +0, and -1) so
far, this does not reach the quorum of 15. I'll extend the term to
2022-06-06 16:00 UTC.

This is a friendly reminder note in case you have missed it in my first post.

*IMPORTANT NOTE*
I set a local protocol for this vote.
There are 95 committers on this project [3] - the vote will be
effective if it successfully gains more than 15% of voters (>= 15)
from committers (including PMC members). This means, that although
only PMC member votes are counted for the final result, the votes from
all committers are important to make the vote result effective.

If there are less than 15 votes at 2022-06-06 16:00 UTC, I will expand
the term to 2022-06-13 16:00 UTC. If this fails to get sufficient
voters after the expanded time limit, I'll cancel this vote regardless
of the result.

Thanks,
Tomoko

2022年6月1日(水) 6:19 Alessandro Benedetti :
>
> +1(committer, non PMC)
>
> Lately I kinda feel having to create the Jira, after I detailed a 
> contribution in the pull request, is just a boilerplate activity of copying 
> and pasting and tagging again.
> I would be happy to reduce this burden.
> I left other details in the discussion thread.
>
> Cheers
>
>
> On Tue, 31 May 2022, 21:19 Jason Gerlowski,  wrote:
>>
>> +1 (PMC)
>>
>> I understand concerns about handing governance over to a 3rd party, but 
>> letting that drive our decision-making here feels like optimizing for a rare 
>> case that might never occur.  I'd m,uch rather optimize for making things 
>> easiest for contributors, and then accommodate any "Github ToS ban, 
>> sanctions, etc." situations if and when they crop up on a case by case basis.
>>
>> Best,
>>
>> Jason
>>
>> On Tue, May 31, 2022 at 10:09 AM Gus Heck  wrote:
>>>
>>> -1 I think the disruption and bifurcation of where to find history is not 
>>> worth it. I also noticed a comment in the lucene issue for migration with 
>>> summaries by date range, status, affects version,  etc. sub-area, exactly 
>>> the sort of thing I expect to be much more difficult to obtain from github. 
>>> What I would find interesting is a deep integration of the two systems so 
>>> that initiation and basic commenting could be handled on github, but 
>>> transmitted to Jira where full metadata and reporting/tracking could be 
>>> maintained.
>>>
>>> On Tue, May 31, 2022 at 12:17 AM Ishan Chattopadhyaya 
>>>  wrote:
>>>>
>>>> -1
>>>>
>>>> On Tue, 31 May, 2022, 4:06 am Xi Chen,  
>>>> wrote:
>>>>>
>>>>> +1 from me (committer, non-PMC)
>>>>>
>>>>> Thanks Tomoko for starting the discussion and organizing / leading this 
>>>>> effort!
>>>>>
>>>>> Best,
>>>>> Zach
>>>>>
>>>>> On May 30, 2022, at 2:56 PM, Houston Putman  wrote:
>>>>>
>>>>> 
>>>>> +1 Approve (PMC)
>>>>>
>>>>> Thanks so much for doing all of the work for this Tomoko!
>>>>>
>>>>> - Houston
>>>>>
>>>>> On Mon, May 30, 2022 at 5:38 PM David Smiley  wrote:
>>>>>>
>>>>>> +1 Approve (PMC)
>>>>>>
>>>>>> ~ David Smiley
>>>>>> Apache Lucene/Solr Search Developer
>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>
>>>>>>
>>>>>> On Mon, May 30, 2022 at 11:40 AM Tomoko Uchida 
>>>>>>  wrote:
>>>>>>>
>>>>>>> Hi everyone!
>>>>>>>
>>>>>>> As we had previous discussion thread [1], I propose migration to GitHub 
>>>>>>> issue from Jira.
>>>>>>> It'd be technically possible (see [2] for details) and I think it'd be 
>>>>>>> good for the project - not only for welcoming new developers who are 
>>>>>>> not familiar with Jira, but also for improving the experiences of 
>>>>>>> long-term committers/contributors by consolidating the conversation 
>>>>>>> platform.
>>>>>>>
>>>>>>> You can see a short summary of the discussion, some stats on current 
>>>>>>> Jira issues, and a draft migration plan in [2].
>>>>>>> Please review [2] if you haven't seen it and vote for this proposal.
>>>>>>>
>>>>>>> The vote will be open unt

Re: [JENKINS] Lucene » Lucene-Check-main - Build # 5746 - Failure!

[Tomoko Uchida]

I don't think anyone ran the job to clean up the gradle cache today,
and the job still fails with:

A problem occurred evaluating root project 'lucene-root'.
> Could not load compiled classes for script 
> '/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Check-main/gradle/validation/validate-source-patterns.gradle'
>  from cache.

As a trial, I will manually run this job and see the results.
https://ci-builds.apache.org/job/Lucene/job/Clean%20up%20Gradle%20cache/

Tomoko

2022年6月7日(火) 3:56 Dawid Weiss :
>
>
> Thanks for clarifying (and fixing) - Tomoko, Kevin. I'm not sure what's 
> causing this either.
>
> Dawid
>
> On Mon, Jun 6, 2022 at 4:16 PM Kevin Risden  wrote:
>>
>> I created the 
>> https://ci-builds.apache.org/job/Solr/job/lucene-solr-1-gradle-cache-cleanup 
>> job since a similar error was seen a few months ago:
>>
>> https://lists.apache.org/thread/jor6ct8l2vpq7x98hxdfn8xnp0ln6xqj
>>
>> It did fix the problem, but was never able to identify the root cause.
>>
>> Kevin Risden
>>
>>
>> On Mon, Jun 6, 2022 at 9:56 AM Tomoko Uchida  
>> wrote:
>>>
>>> I was able to log in to the ASF Jenkins Console and created this job
>>> that just deletes the whole gradle cache folder on nodes that are
>>> labeled "lucene" (please see the job configuration).
>>> https://ci-builds.apache.org/job/Lucene/job/Clean%20up%20Gradle%20cache/
>>>
>>> I didn't set a schedule for the job and haven't executed it yet (it
>>> may affect all running Lucene jobs) but I think I or anyone with an
>>> ASF account can manually run it.
>>>
>>> 2022年6月6日(月) 15:18 Dawid Weiss :
>>> >
>>> >
>>> > This seems like a gradle cache problem somehow:
>>> >
>>> > Could not load compiled classes for script 
>>> > '/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Check-main/gradle/validation/validate-source-patterns.gradle'
>>> >  from cache.
>>> >
>>> >
>>> > I'm not sure how to fix it on those agent machines - I see a jenkins job 
>>> > with this name:
>>> >
>>> >
>>> > https://ci-builds.apache.org/job/Solr/job/lucene-solr-1-gradle-cache-cleanup
>>> >
>>> >
>>> > But this is disabled... Has anybody experienced this before (whoever 
>>> > created that job)?
>>> >
>>> >
>>> > Dawid
>>> >
>>> >
>>> > On Mon, Jun 6, 2022 at 6:54 AM Apache Jenkins Server 
>>> >  wrote:
>>> >>
>>> >> Build: 
>>> >> https://ci-builds.apache.org/job/Lucene/job/Lucene-Check-main/5746/
>>> >>
>>> >> No tests ran.
>>> >>
>>> >> Build Log:
>>> >> [...truncated 73 lines...]
>>> >> BUILD FAILED in 12s
>>> >> 2 actionable tasks: 2 executed
>>> >> Build step 'Invoke Gradle script' changed build result to FAILURE
>>> >> Build step 'Invoke Gradle script' marked build as failure
>>> >> Archiving artifacts
>>> >> Recording test results
>>> >> ERROR: Step ‘Publish JUnit test result report’ failed: No test report 
>>> >> files were found. Configuration error?
>>> >> Email was triggered for: Failure - Any
>>> >> Sending email for trigger: Failure - Any
>>> >>
>>> >> -
>>> >> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
>>> >> For additional commands, e-mail: builds-h...@lucene.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene » Lucene-Check-main - Build # 5746 - Failure!

[Tomoko Uchida]

I was able to log in to the ASF Jenkins Console and created this job
that just deletes the whole gradle cache folder on nodes that are
labeled "lucene" (please see the job configuration).
https://ci-builds.apache.org/job/Lucene/job/Clean%20up%20Gradle%20cache/

I didn't set a schedule for the job and haven't executed it yet (it
may affect all running Lucene jobs) but I think I or anyone with an
ASF account can manually run it.

2022年6月6日(月) 15:18 Dawid Weiss :
>
>
> This seems like a gradle cache problem somehow:
>
> Could not load compiled classes for script 
> '/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Check-main/gradle/validation/validate-source-patterns.gradle'
>  from cache.
>
>
> I'm not sure how to fix it on those agent machines - I see a jenkins job with 
> this name:
>
>
> https://ci-builds.apache.org/job/Solr/job/lucene-solr-1-gradle-cache-cleanup
>
>
> But this is disabled... Has anybody experienced this before (whoever created 
> that job)?
>
>
> Dawid
>
>
> On Mon, Jun 6, 2022 at 6:54 AM Apache Jenkins Server 
>  wrote:
>>
>> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Check-main/5746/
>>
>> No tests ran.
>>
>> Build Log:
>> [...truncated 73 lines...]
>> BUILD FAILED in 12s
>> 2 actionable tasks: 2 executed
>> Build step 'Invoke Gradle script' changed build result to FAILURE
>> Build step 'Invoke Gradle script' marked build as failure
>> Archiving artifacts
>> Recording test results
>> ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
>> were found. Configuration error?
>> Email was triggered for: Failure - Any
>> Sending email for trigger: Failure - Any
>>
>> -
>> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: builds-h...@lucene.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: module not found error in intellij

[Tomoko Uchida]

Thanks for confirming, just to be clear - the module descriptor
shouldn't affect the existing (in-module) tests, you can run them with
a debugger with IDEs.
Problems can happen when running the inter-module tests via IDE (we
have three, lucene/core.tests, lucene/analysis.tests, and
lucene/distribution.tests. I've seen lucene/core.tests and
lucene/analysis.tests fail with different errors,
lucene/distribution.tests passes).


2022年6月3日(金) 1:22 Michael Sokolov :
>
> I was able to run tests in IDEA by removing all the module-info.jar,
> so indeed, seems to be some kind of interaction with modules
>
> On Thu, Jun 2, 2022 at 11:36 AM Tomoko Uchida
>  wrote:
> >
> > Yes I agree with there may be bugs (I couldn't find the corresponding
> > issue in IDEA's issue tracker), they are just not our bugs...
> >
> >
> > 2022年6月3日(金) 0:17 Michael Sokolov :
> > >
> > > glad to know I'm not the only one! I think it's not OK though. Running
> > > tests in IDE is super useful, especially for debugging, but also for
> > > visualizing coverage. I think there must be a bug; we do say:
> > >
> > > 11:15 $ ./gradlew helpIDEs
> > >
> > > > Task :helpIDEs
> > >
> > > IntelliJ IDEA
> > > =
> > >
> > > Importing the project as a gradle project should just run out of the box.
> > >
> > > On Thu, Jun 2, 2022 at 11:11 AM Tomoko Uchida
> > >  wrote:
> > > >
> > > > Hi Mike,
> > > > I also can't run the tests in lucene/core.tests with IntelliJ IDEA,
> > > > but it should be able to run with the plain gradle command from a
> > > > console.
> > > > ./gradlew -p lucene/core.tests/ test
> > > >
> > > > I'm not sure the exact cause of that though IDEs' java module support
> > > > looks far from perfect for now, I would recommend not to use IDE when
> > > > running modular tests...
> > > >
> > > > Tomoko
> > > >
> > > > 2022年6月2日(木) 23:44 Michael Sokolov :
> > > > >
> > > > > In IntelliJ building Lucene main branch I see this:
> > > > >
> > > > > .../workspace/lucene/lucene/core.tests/src/test/module-info.java:23:
> > > > > error: module not found: org.apache.lucene.core.tests.main
> > > > >   requires org.apache.lucene.core.tests.main;
> > > > >^
> > > > >
> > > > > Am I doing it wrong? Does anybody else encounter this? I tried
> > > > > re-importing the Gradle model, which succeeds, but then when I build
> > > > > the project I get the above error.
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: module not found error in intellij

[Tomoko Uchida]

Yes I agree with there may be bugs (I couldn't find the corresponding
issue in IDEA's issue tracker), they are just not our bugs...


2022年6月3日(金) 0:17 Michael Sokolov :
>
> glad to know I'm not the only one! I think it's not OK though. Running
> tests in IDE is super useful, especially for debugging, but also for
> visualizing coverage. I think there must be a bug; we do say:
>
> 11:15 $ ./gradlew helpIDEs
>
> > Task :helpIDEs
>
> IntelliJ IDEA
> =
>
> Importing the project as a gradle project should just run out of the box.
>
> On Thu, Jun 2, 2022 at 11:11 AM Tomoko Uchida
>  wrote:
> >
> > Hi Mike,
> > I also can't run the tests in lucene/core.tests with IntelliJ IDEA,
> > but it should be able to run with the plain gradle command from a
> > console.
> > ./gradlew -p lucene/core.tests/ test
> >
> > I'm not sure the exact cause of that though IDEs' java module support
> > looks far from perfect for now, I would recommend not to use IDE when
> > running modular tests...
> >
> > Tomoko
> >
> > 2022年6月2日(木) 23:44 Michael Sokolov :
> > >
> > > In IntelliJ building Lucene main branch I see this:
> > >
> > > .../workspace/lucene/lucene/core.tests/src/test/module-info.java:23:
> > > error: module not found: org.apache.lucene.core.tests.main
> > >   requires org.apache.lucene.core.tests.main;
> > >^
> > >
> > > Am I doing it wrong? Does anybody else encounter this? I tried
> > > re-importing the Gradle model, which succeeds, but then when I build
> > > the project I get the above error.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: module not found error in intellij

[Tomoko Uchida]

Hi Mike,
I also can't run the tests in lucene/core.tests with IntelliJ IDEA,
but it should be able to run with the plain gradle command from a
console.
./gradlew -p lucene/core.tests/ test

I'm not sure the exact cause of that though IDEs' java module support
looks far from perfect for now, I would recommend not to use IDE when
running modular tests...

Tomoko

2022年6月2日(木) 23:44 Michael Sokolov :
>
> In IntelliJ building Lucene main branch I see this:
>
> .../workspace/lucene/lucene/core.tests/src/test/module-info.java:23:
> error: module not found: org.apache.lucene.core.tests.main
>   requires org.apache.lucene.core.tests.main;
>^
>
> Am I doing it wrong? Does anybody else encounter this? I tried
> re-importing the Gradle model, which succeeds, but then when I build
> the project I get the above error.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Lucene 9.2 release

[Tomoko Uchida]

Hi all,
Just a minor heads-up.
We will have a more fine-grained Java version check when starting
gradlew command shortly.
After PR #941 is merged into main, you need newer Java (17.0.3) for a build.

2022年5月18日(水) 19:00 Tomoko Uchida :
>
> Hi, I just wanted to note that I opened LUCENE-10578.
> Maybe it'd be worth having the discussion in Jira?
>
>
> 2022年5月18日(水) 18:31 Alan Woodward :
>>
>> I think this release is the first time I’ve used Java 11 since 2019, yes!
>>
>> I’ll get the latest AdoptOpenJDK version and try and persuade my Mac to use 
>> it...
>>
>> > On 18 May 2022, at 10:19, Dawid Weiss  wrote:
>> >
>> > Living in the past, aren't we? :)
>> >
>> > D.
>> >
>> > On Wed, May 18, 2022 at 10:49 AM Alan Woodward  
>> > wrote:
>> >>
>> >> $ /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java 
>> >> -version
>> >>
>> >> openjdk version "11" 2018-09-25
>> >> OpenJDK Runtime Environment 18.9 (build 11+28)
>> >> OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
>> >>
>> >>
>> >>> On 18 May 2022, at 09:35, Dawid Weiss  wrote:
>> >>>
>> >>> Alan, what's the exact JDK vendor/ release number you used that had
>> >>> this problem? If we can reproduce it then we'd know where to look
>> >>> (bisect until we know javadoc works correctly).
>> >>>
>> >>> D.
>> >>>
>> >>> On Wed, May 18, 2022 at 10:33 AM Dawid Weiss  
>> >>> wrote:
>> >>>>
>> >>>>> I'd like to draw attention to my second question while we are still 
>> >>>>> here... should we limit the OpenJDK distribution (for building)? My 
>> >>>>> worry here is, that minor versions could depend on the distributor.
>> >>>>
>> >>>> This is a valid concern but it'd take some trial and error to verify
>> >>>> which version numbers are used by packaging openjdk for various
>> >>>> releases. Realistically, the JDK part (standard library) is nearly the
>> >>>> same in all/ most of them? The least that could be done is to apply
>> >>>> the restriction to just a particular vendor/ release and emit a
>> >>>> warning for unrecognized ones.
>> >>>>
>> >>>> Dawid
>> >>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Lu Xugang as Lucene committer

[Tomoko Uchida]

Congratulations and welcome, Lu Xugang!

(Can we call you by your full name as your signature, or do you have
any preference on that? I use my first name here, some Asian people
use their nicknames, etc.)

Tomoko


2022年6月1日(水) 23:16 Nhat Nguyen :

>
> Congrats, Lu Xugang!
>
> On Wed, Jun 1, 2022 at 8:50 AM Greg Miller  wrote:
>>
>> Welcome Lu Xugang!
>>
>> On Wed, Jun 1, 2022 at 2:04 PM Mayya Sharipova
>>  wrote:
>> >
>> > Congratulations and welcome, Lu Xugang!
>> >
>> > On Wed, Jun 1, 2022 at 7:53 AM Jan Høydahl  wrote:
>> >>
>> >> Welcome and congratulations!
>> >>
>> >> Jan
>> >>
>> >> > 1. jun. 2022 kl. 09:07 skrev Adrien Grand :
>> >> >
>> >> > I'm pleased to announce that Lu Xugang has accepted the PMC's
>> >> > invitation to become a committer.
>> >> >
>> >> > Xugang, the tradition is that new committers introduce themselves with a
>> >> > brief bio.
>> >> >
>> >> > Congratulations and welcome!
>> >> >
>> >> > --
>> >> > Adrien
>> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Chris Hegarty as Lucene committer

[Tomoko Uchida]

Congratulations and welcome, Chris!

Tomoko


2022年6月1日(水) 23:17 Nhat Nguyen :

> Welcome, Chris!
>
> On Wed, Jun 1, 2022 at 8:49 AM Greg Miller  wrote:
>
>> Welcome Chris!
>>
>> On Wed, Jun 1, 2022 at 2:04 PM Mayya Sharipova
>>  wrote:
>> >
>> > Welcome and congratulations, Chris!
>> >
>> > On Wed, Jun 1, 2022 at 7:53 AM Jan Høydahl 
>> wrote:
>> >>
>> >> Welcome Chris!
>> >>
>> >> Jan
>> >>
>> >> > 1. jun. 2022 kl. 09:04 skrev Adrien Grand :
>> >> >
>> >> > I'm pleased to announce that Chris Hegarty has accepted the PMC's
>> >> > invitation to become a committer.
>> >> >
>> >> > Chris, the tradition is that new committers introduce themselves
>> with a
>> >> > brief bio.
>> >> >
>> >> > Congratulations and welcome!
>> >> >
>> >> > --
>> >> > Adrien
>> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: [VOTE] Migration to GitHub issue from Jira (LUCENE-10557)

[Tomoko Uchida]

Hi,
thank you for participating for this!

I may need to clarify the local rule I set.
"15 votes" threshold means literally 15 votes, that includes approval(+1),
disapproval(-1), and no opinion(+0).
I don't mean we need 15 approvals or 15 disapprovals to make the dicision -
it could be too high hurdle for both side I think.

I mean, I need at least "15 participants" who pay attention/take time on it
and decide to cast their valuable votes for this proposal.

Thanks,
Tomoko


2022年5月31日(火) 4:04 Dragan Ivanovic :

> Hello everyone,
>
> Not sure whether this email might help you, but let me share the VIVO
> community experience with this issue. We have migrated JIRA issues
> available at
> https://vivo-project.atlassian.net/jira/software/c/projects/VIVO/issues/
> to GitHub issues available at https://github.com/vivo-project/VIVO/issues.
> We used a customized version of this project -
> https://github.com/rstoyanchev/jira-to-gh-issues  (our customization is
> available at https://github.com/chenejac/jira-to-gh-issues). Basically,
> it is possible to migrate issues, not perfect, but majority of information
> is there, and we are happy with our decision to move to GitHub issues.
>
> Good luck with migration.
>
> Regards,
>
> Dragan Ivanovic
>
> the VIVO tech lead
> On 5/30/2022 8:53 PM, Patrick Zhai wrote:
>
> Thank you Tomoko for starting the vote, although I didn't participate in
> the last discussion but I'd love to see us moving towards the github issue.
>
> So here's my +1 (committer, non-PMC)
>
> BTW, by "the vote will be effective if it successfully gains more than 15%
> of voters (>= 15) from committers", do you mean to make it successful we
> need to collect 15 "+1" from committers or just 15 votes (regardless of the
> opinion)?
>
> Best
> Patrick
>
> On Mon, May 30, 2022 at 8:41 AM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
>> Hi everyone!
>>
>> As we had previous discussion thread [1], I propose migration to GitHub
>> issue from Jira.
>> It'd be technically possible (see [2] for details) and I think it'd be
>> good for the project - not only for welcoming new developers who are not
>> familiar with Jira, but also for improving the experiences of long-term
>> committers/contributors by consolidating the conversation platform.
>>
>> You can see a short summary of the discussion, some stats on current Jira
>> issues, and a draft migration plan in [2].
>> Please review [2] if you haven't seen it and vote for this proposal.
>>
>> The vote will be open until 2022-06-06 16:00 UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1
>>
>> *IMPORTANT NOTE*
>> I set a local protocol for this vote.
>> There are 95 committers on this project [3] - the vote will be effective
>> if it successfully gains more than 15% of voters (>= 15) from committers
>> (including PMC members). This means, that although only PMC member votes
>> are counted for the final result, the votes from all committers are
>> important to make the vote result effective.
>>
>> If there are less than 15 votes at 2022-06-06 16:00 UTC, I will expand
>> the term to 2022-06-13 16:00 UTC. If this fails to get sufficient voters
>> after the expanded time limit, I'll cancel this vote regardless of the
>> result.
>> But why do I set such an extra bar? My fear is that if such things are
>> decided by the opinions of a few members, the result shouldn't yield a good
>> outcome for the future. It isn't my goal to just pass the vote [4].
>>
>> [1] https://lists.apache.org/thread/78wj0vll73sct065m5jjm4z8gqb5yffk
>> [2] https://issues.apache.org/jira/browse/LUCENE-10557
>> [3] https://projects.apache.org/committee.html?lucene
>> [4] I'm sorry for being overly cautious, but I have never met in person
>> or virtually any of the committers (with a very few exceptions), therefore
>> cannot assess if the vote result is reliable or not unless there is certain
>> explicit feedback.
>>
>> Tomoko
>>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=link>
> <#m_-2736906657232979281_m_-7706922548550600098_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

[VOTE] Migration to GitHub issue from Jira (LUCENE-10557)

[Tomoko Uchida]

Hi everyone!

As we had previous discussion thread [1], I propose migration to GitHub
issue from Jira.
It'd be technically possible (see [2] for details) and I think it'd be good
for the project - not only for welcoming new developers who are not
familiar with Jira, but also for improving the experiences of long-term
committers/contributors by consolidating the conversation platform.

You can see a short summary of the discussion, some stats on current Jira
issues, and a draft migration plan in [2].
Please review [2] if you haven't seen it and vote for this proposal.

The vote will be open until 2022-06-06 16:00 UTC.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1

*IMPORTANT NOTE*
I set a local protocol for this vote.
There are 95 committers on this project [3] - the vote will be effective if
it successfully gains more than 15% of voters (>= 15) from committers
(including PMC members). This means, that although only PMC member votes
are counted for the final result, the votes from all committers are
important to make the vote result effective.

If there are less than 15 votes at 2022-06-06 16:00 UTC, I will expand the
term to 2022-06-13 16:00 UTC. If this fails to get sufficient voters after
the expanded time limit, I'll cancel this vote regardless of the result.
But why do I set such an extra bar? My fear is that if such things are
decided by the opinions of a few members, the result shouldn't yield a good
outcome for the future. It isn't my goal to just pass the vote [4].

[1] https://lists.apache.org/thread/78wj0vll73sct065m5jjm4z8gqb5yffk
[2] https://issues.apache.org/jira/browse/LUCENE-10557
[3] https://projects.apache.org/committee.html?lucene
[4] I'm sorry for being overly cautious, but I have never met in person or
virtually any of the committers (with a very few exceptions), therefore
cannot assess if the vote result is reliable or not unless there is certain
explicit feedback.

Tomoko

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Tomoko Uchida]

Hi all,

I did some surveys on current Jira issue stats and operational policies on
other projects that are operated on GitHub.
Here's a summary.

[Issue stats on 28/May/2022]
# of total issues: 10543
# of unresolved issues: 1914

Breakdown of unresolved issues
By Issue Type
- Type="Bug": 679
- Type="Improvement": 790
- Type="New Feature": 173
- ...

You can see more detailed numbers on LUCENE-10557
<https://issues.apache.org/jira/browse/LUCENE-10557>.

[Operational policies in other projects on GitHub]
I randomly selected some large/popular projects including ASF projects for
this - Kubernetes, Elasticsearch, OpenSearch, Apache Solr Operator, Apache
Airflow, Apache Lucene.NET, Spring Framework, and Gradle.
I don't explain the whole details here, please see the issue comment on
LUCENE-10557.

And I drafted an early migration plan on the issue.

I'm going to close this discussion and open a vote next week - in the
meantime, please review the summaries of the conversation here on
LUCENE-10557 and join the vote.

I'd also like to set a local protocol for the vote.
There are 95 committers (including PMC members) [1] - the vote will be
effective if it successfully gains more than 15% of votes from committers
(>= 15) in a reasonable time period. Otherwise, I'll cancel the vote.
This means, that only PMC members' votes are counted for the final result,
but the votes of all committers are important to make the vote effective.
But why set such an extra bar? My fear is that if such things are decided
by the opinions of a few members, the result shouldn't yield a good result
for the future. It isn't my goal to just pass the vote.

[1] https://projects.apache.org/committee.html?lucene

Tomoko

Tomoko


2022年5月26日(木) 10:17 Tomoko Uchida :

> We have been having a very long discussion many issues are posed, thank
> you everyone who is involved.
> Here is a short, non-exhaustive summary of posed issues/questions (with my
> brief thoughts/opinions) so far.
>
>  * Concerns for political neutrality of GitHub - in other words, concerns
> for account bans with no good reason
> ** Seems there are several cases of GitHub account bans. It's unclear
> whether they violated its terms of policy or not, and to me, we won't be
> able to correctly assess the risk. I would defer the judgment to the
> individuals.
> ** For developers who don't use GitHub for whatever reason, we will
> always support contribution paths that do not rely on GitHub. Patches via
> Jira will be a decent option for good.
>
>  * Concerns for its parent company, Microsoft
> ** I'd defer the judgment on that to the individuals for the same
> reason for the previous subject. One thing I could say is, that the recent
> trend in their direction is GOOD - they support/sponsor open source and
> Java communities and even publish very popular open-source software (VSCode
> and LightGBM are outstanding examples I think).
>
>  * Concerns for lack of issue workflow and simpler metadata management
> ** From the practical viewpoint, it fully makes sense to me that many
> people talked about it. We would need to carefully think of how to control
> versions and issue/PR metadata. Large projects that are fully operated on
> GitHub overcome this shortcoming in various ways - organized issue
> templates with fixed label sets would be an example. I think we will have a
> sandbox repository outside ASF, then try some experiments on it before
> actual migration.
>
>  * Security issues that only PMC members are allowed to be accessed
> ** We will be able to continue to use Jira for this purpose, or we
> could even have an issue-only private GitHub repository for Lucene?
>
> * Concerns for migration of whole existing Jira issue history to GitHub
> issue
>** I don't think it is possible. I'm almost sure there will be some
> information losses if we attempt to migrate the whole Jira issue with
> metadata/history into Github. Rather than trying to do that, I would prefer
> to let Jira issues as is, then simply refer them.
>** If we don't aim at perfection, I think we'll be able to migrate all
> (or part of) issues with APIs as Shad Storhaug kindly shared in the issue
> comment[1].
>
> [1]
> https://issues.apache.org/jira/browse/LUCENE-10557?focusedCommentId=17535898=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17535898
>
> Aside from those concerns, there seems no disagreement with GitHub is
> superior to Jira in terms of overall UX design, and most new developers
> like it.
>
> I'm planning to make a VOTE thread but before that, I'll do some surveys
> on Jira issue stats (# of total issues, # of unresolved issues, etc.) and
> large/popular projects that are hosted on GitHub so that we can make a
> clearer image on how things