Mailing List Archive

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 <lucene@mikemccandless.com>:

> 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
>

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.1111@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 <lucene@mikemccandless.com>:
>
>> 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
>>
>

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 <msokolov@gmail.com>:

> 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.1111@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 <lucene@mikemccandless.com>:
>>
>>> 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
>>>
>>

Indeed, GitHub forbids you from attaching a file with extension .patch!
Sort of annoying :)

But then one workaround is to rename it to XXXX-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.1111@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 <msokolov@gmail.com>:
>
>> 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.1111@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 <lucene@mikemccandless.com>:
>>>
>>>> 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
>>>>
>>>

I see. If we forbid people from updating Jira, I hope we will keep dealing
with .patch files (maybe renamed to XXXX.patch.txt or XXXX-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 <lucene@mikemccandless.com>:

> Indeed, GitHub forbids you from attaching a file with extension .patch!
> Sort of annoying :)
>
> But then one workaround is to rename it to XXXX-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.1111@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 <msokolov@gmail.com>:
>>
>>> 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.1111@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 <lucene@mikemccandless.com>:
>>>>
>>>>> 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
>>>>>
>>>>

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 <
lucene@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
>

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 <dsmiley@apache.org> 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 <
> lucene@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)

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 <gus.heck@gmail.com>:

> 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 <dsmiley@apache.org> 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 <
>> lucene@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)
>

> 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.1111@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 <gus.heck@gmail.com>:
>
>> 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 <dsmiley@apache.org> 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 <
>>> lucene@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)
>>
>

> 1. Make Jira read only

At the very last step, we'll add comments saying "This was moved GitHub
<URL>" 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 <ryan@iernst.net>:

> > 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.1111@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 <gus.heck@gmail.com>:
>>
>>> 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 <dsmiley@apache.org>
>>> 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 <
>>>> lucene@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)
>>>
>>

On Tue, Jul 19, 2022 at 8:48 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> > 1. Make Jira read only
>
> At the very last step, we'll add comments saying "This was moved GitHub
> <URL>" 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.


> > 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 <ryan@iernst.net>:
>
>> > 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.1111@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 <gus.heck@gmail.com>:
>>>
>>>> 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 <dsmiley@apache.org>
>>>> 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 <
>>>>> lucene@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)
>>>>
>>>

> 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 <tomoko.uchida.1111@gmail.com>:

> > 1. Make Jira read only
>
> At the very last step, we'll add comments saying "This was moved GitHub
> <URL>" 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 <ryan@iernst.net>:
>
>> > 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.1111@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 <gus.heck@gmail.com>:
>>>
>>>> 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 <dsmiley@apache.org>
>>>> 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 <
>>>>> lucene@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)
>>>>
>>>

>
> > 1. Make Jira read only
>
> At the very last step, we'll add comments saying "This was moved GitHub
> <URL>" 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 <tomoko.uchida.1111@gmail.com>:

> > 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 <tomoko.uchida.1111@gmail.com>:
>
>> > 1. Make Jira read only
>>
>> At the very last step, we'll add comments saying "This was moved GitHub
>> <URL>" 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 <ryan@iernst.net>:
>>
>>> > 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.1111@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 <gus.heck@gmail.com>:
>>>>
>>>>> 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 <dsmiley@apache.org>
>>>>> 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 <
>>>>>> lucene@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)
>>>>>
>>>>

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.1111@gmail.com>
wrote:

> > 1. Make Jira read only
>>
>> At the very last step, we'll add comments saying "This was moved GitHub
>> <URL>" 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 <tomoko.uchida.1111@gmail.com>:
>
>> > 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 <tomoko.uchida.1111@gmail.com>:
>>
>>> > 1. Make Jira read only
>>>
>>> At the very last step, we'll add comments saying "This was moved GitHub
>>> <URL>" 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 <ryan@iernst.net>:
>>>
>>>> > 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.1111@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 <gus.heck@gmail.com>:
>>>>>
>>>>>> 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 <dsmiley@apache.org>
>>>>>> 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 <
>>>>>>> lucene@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)
>>>>>>
>>>>>

>
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 <tomoko.uchida.1111@gmail.com>:

> > 1. Make Jira read only
>>
>> At the very last step, we'll add comments saying "This was moved GitHub
>> <URL>" 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 <tomoko.uchida.1111@gmail.com>:
>
>> > 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 <tomoko.uchida.1111@gmail.com>:
>>
>>> > 1. Make Jira read only
>>>
>>> At the very last step, we'll add comments saying "This was moved GitHub
>>> <URL>" 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 <ryan@iernst.net>:
>>>
>>>> > 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.1111@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 <gus.heck@gmail.com>:
>>>>>
>>>>>> 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 <dsmiley@apache.org>
>>>>>> 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 <
>>>>>>> lucene@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)
>>>>>>
>>>>>

> 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 <houstonputman@gmail.com>:

> 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.1111@gmail.com> wrote:
>
>> > 1. Make Jira read only
>>>
>>> At the very last step, we'll add comments saying "This was moved GitHub
>>> <URL>" 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 <tomoko.uchida.1111@gmail.com>:
>>
>>> > 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 <tomoko.uchida.1111@gmail.com>:
>>>
>>>> > 1. Make Jira read only
>>>>
>>>> At the very last step, we'll add comments saying "This was moved GitHub
>>>> <URL>" 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 <ryan@iernst.net>:
>>>>
>>>>> > 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.1111@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 <gus.heck@gmail.com>:
>>>>>>
>>>>>>> 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 <dsmiley@apache.org>
>>>>>>> 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 <
>>>>>>>> lucene@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)
>>>>>>>
>>>>>>

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 <tomoko.uchida.1111@gmail.com>:

> > 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 <houstonputman@gmail.com>:
>
>> 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.1111@gmail.com> wrote:
>>
>>> > 1. Make Jira read only
>>>>
>>>> At the very last step, we'll add comments saying "This was moved GitHub
>>>> <URL>" 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 <tomoko.uchida.1111@gmail.com>:
>>>
>>>> > 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 <tomoko.uchida.1111@gmail.com>:
>>>>
>>>>> > 1. Make Jira read only
>>>>>
>>>>> At the very last step, we'll add comments saying "This was moved
>>>>> GitHub <URL>" 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 <ryan@iernst.net>:
>>>>>
>>>>>> > 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.1111@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 <gus.heck@gmail.com>:
>>>>>>>
>>>>>>>> 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 <dsmiley@apache.org>
>>>>>>>> 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 <
>>>>>>>>> lucene@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)
>>>>>>>>
>>>>>>>