Mailing List Archive

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

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

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

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

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

Maybe a 3rd option could be to only use GitHub for new issues by adding
some text to the Jira create issue dialog that says something like "JIRA is
deprecated, please use GitHub for new issues" to encourage users to create
new issues on GitHub instead of JIRA.

On Wed, Jun 15, 2022 at 11:40 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> Hi all,
> there is one thing we need to decide for the migration.
>
> I think we can migrate the whole issue in Jira (we have 10,000+ issues
> in total) though, I am thinking of migrating only unresolved issues.
> Already closed issues can remain Jira as history and can be
> referred/searched when it's needed, I think.
> I'm not going to screen issues by any criteria such as creation date -
> can't estimate what issue is obsoleted or not.
> If you have any suggestions on it, please let me know by replying to
> this mail or leaving comments on the Jira.
>
> It'll take some time for me so thank you for your patience.
> Tomoko
>
> 2022?6?14?(?) 16:41 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
> >
> > It's been >7d since the vote was initiated and the result is:
> >
> > +1 16 (12 binding)
> > +0 3 (3 binding)
> > -1 3 (3 binding)
> >
> > This vote has PASSED.
> >
> > Thanks to everyone who is involved in the discussion and/or voted.
> > The work will continue on LUCENE-10557.
> >
> > Best,
> > Tomoko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

--
Adrien

> Maybe a 3rd option could be to only use GitHub for new issues by adding
> some text to the Jira create issue dialog that says something like "JIRA is
> deprecated, please use GitHub for new issues" to encourage users to create
> new issues on GitHub instead of JIRA.
>

I was thinking this too, actually. It'd allow for a more graceful
transition period from one system to another. It'd also help keep
cross-links (from comments, etc.) in the old issues reference proper
targets. And I don't see many disadvantages - I imagine that folks who wish
to revisit old(er) open Jira issues and prefer GH can close the jira ticket
as a duplicate and open a new corresponding GH issue. Wouldn't this be
easier (for you as well)? The key change would be procedural -- allow pull
requests and github issues as first-class "change" tickets.

D.

>

+1 for a manual approach

Over time the volume will gravitate to mostly GitHub issues. And JIRA will always remain as an archive, so nothing is lost. Devs can always peek into the list of open JIRAs any time and choose to start a PR for one. A slight disadvantage is of course that in the first year or two you need to look in both systems to get a full overview of all open issues. But auto migrating hundreds of abandoned JIRA issues to GitHub is no better imo.

Jan

> 15. jun. 2022 kl. 13:03 skrev Dawid Weiss <dawid.weiss@gmail.com>:
>
>
> Maybe a 3rd option could be to only use GitHub for new issues by adding some text to the Jira create issue dialog that says something like "JIRA is deprecated, please use GitHub for new issues" to encourage users to create new issues on GitHub instead of JIRA.
>
> I was thinking this too, actually. It'd allow for a more graceful transition period from one system to another. It'd also help keep cross-links (from comments, etc.) in the old issues reference proper targets. And I don't see many disadvantages - I imagine that folks who wish to revisit old(er) open Jira issues and prefer GH can close the jira ticket as a duplicate and open a new corresponding GH issue. Wouldn't this be easier (for you as well)? The key change would be procedural -- allow pull requests and github issues as first-class "change" tickets.
>
> D.

Agree with everyone here. Also consider that if we duplicate there
will be two copies of the same issue, and they will inevitably
diverge...

On Wed, Jun 15, 2022 at 9:28 AM Jan Høydahl <jan.asf@cominvent.com> wrote:
>
> +1 for a manual approach
>
> Over time the volume will gravitate to mostly GitHub issues. And JIRA will always remain as an archive, so nothing is lost. Devs can always peek into the list of open JIRAs any time and choose to start a PR for one. A slight disadvantage is of course that in the first year or two you need to look in both systems to get a full overview of all open issues. But auto migrating hundreds of abandoned JIRA issues to GitHub is no better imo.
>
> Jan
>
> 15. jun. 2022 kl. 13:03 skrev Dawid Weiss <dawid.weiss@gmail.com>:
>
>
>> Maybe a 3rd option could be to only use GitHub for new issues by adding some text to the Jira create issue dialog that says something like "JIRA is deprecated, please use GitHub for new issues" to encourage users to create new issues on GitHub instead of JIRA.
>
>
> I was thinking this too, actually. It'd allow for a more graceful transition period from one system to another. It'd also help keep cross-links (from comments, etc.) in the old issues reference proper targets. And I don't see many disadvantages - I imagine that folks who wish to revisit old(er) open Jira issues and prefer GH can close the jira ticket as a duplicate and open a new corresponding GH issue. Wouldn't this be easier (for you as well)? The key change would be procedural -- allow pull requests and github issues as first-class "change" tickets.
>
> D.
>
>

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

I would prefer that we migrate all issues to GitHub and then make the Jira
project read only.

There is a rich history to our project in these issues that we should not
discard. This is a unique property of Apache Lucene since our project has
been in existence and so vibrant for so much time. Those who do not
know/study history are doomed to repeat it :)

Expecting new developers to remember to "oh, long ago this project used
this old thing called Jira, you have to go search that, to find out why XYZ
was done this way in Lucene, pre-Github-issue-migration" is not a good
solution -- many won't remember (nor eventually, know) to do so.

If I saw it correctly, at least two other projects (or maybe two people
from the same project, not sure) created a one-off tool to perform the
migration for their projects. It isn't perfect of course (GitHub issues
may not be able to represent all metadata that Jira has), but we should
migrate what is possible.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Jun 15, 2022 at 9:34 AM Michael Sokolov <msokolov@gmail.com> wrote:

> Agree with everyone here. Also consider that if we duplicate there
> will be two copies of the same issue, and they will inevitably
> diverge...
>
> On Wed, Jun 15, 2022 at 9:28 AM Jan Høydahl <jan.asf@cominvent.com> wrote:
> >
> > +1 for a manual approach
> >
> > Over time the volume will gravitate to mostly GitHub issues. And JIRA
> will always remain as an archive, so nothing is lost. Devs can always peek
> into the list of open JIRAs any time and choose to start a PR for one. A
> slight disadvantage is of course that in the first year or two you need to
> look in both systems to get a full overview of all open issues. But auto
> migrating hundreds of abandoned JIRA issues to GitHub is no better imo.
> >
> > Jan
> >
> > 15. jun. 2022 kl. 13:03 skrev Dawid Weiss <dawid.weiss@gmail.com>:
> >
> >
> >> Maybe a 3rd option could be to only use GitHub for new issues by adding
> some text to the Jira create issue dialog that says something like "JIRA is
> deprecated, please use GitHub for new issues" to encourage users to create
> new issues on GitHub instead of JIRA.
> >
> >
> > I was thinking this too, actually. It'd allow for a more graceful
> transition period from one system to another. It'd also help keep
> cross-links (from comments, etc.) in the old issues reference proper
> targets. And I don't see many disadvantages - I imagine that folks who wish
> to revisit old(er) open Jira issues and prefer GH can close the jira ticket
> as a duplicate and open a new corresponding GH issue. Wouldn't this be
> easier (for you as well)? The key change would be procedural -- allow pull
> requests and github issues as first-class "change" tickets.
> >
> > D.
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

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

> make the Jira project read only.

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

Tomoko

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

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

Totally agree. The history of closed issues answer “when did this change and why?”. Migrate them all. Computers can do that. It avoids asking humans to think about where stuff is.

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

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

On Wed, Jun 15, 2022 at 10:46 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

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

I see you already have a start at the migration plan, yay! (The comment on
LUCENE-10557)

Could we maybe pull that out into a wiki page so we can more easily
collaborate on the steps?


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

Hmm, I think it's quite risky/dangerous to leave both writable? It'd be
forking our issue tracker. We'll have situations where some of us update
the Jira issue, others update the GitHub issue, we lose context/comments,
we duplicate work (thinking nobody is working on the GitHub issue yet
someone was actually working on the Jira one). It would add
risk/friction/taxation to development going forward ... people would need
to know to check two places (GitHub and Jira) for updates, new issues,
patches, linked PRs, etc.

To me the migration would ideally be an atomic switch -- only Jira is
writeable up until some point, then it goes read only, we kick off the
(hopefully already well tested/debugged migration tool, probably just
forking this nice tool that the Lucene.net devs created
<https://github.com/bongohrtech/jira-issues-importer/tree/lucenenet>), then
GitHub issues is writable.

This nicely matches how SVN -> Git migration went.

Yes, some people are not fully comfortable with GitHub, yet, but we expect
that to be the minority, we expect account blocking to be rare and easy to
resolve, etc. (since our VOTE to migrate has passed).

I really feel we should make a hard switch for the best long-term health of
the dev community.

Mike McCandless

http://blog.mikemccandless.com

I agree with the idea that we shouldn't have 2 active trackers, but I think
that the apache jira must remain readable forever. People will have
bookmarked or linked issues in documents, blog posts or web pages and
breaking those links would be a HUGE disservice to the community. Ideally
we would set Jira to not accept new issues and lock out comments on closed
issues. New issues would then appear in github. If we were able to migrate
a locked, read only copy of closed jira's into github (and include a link
back to the original) that might be of some help to users so they can work
in github and ignore Jira, but we should not allow further discussion in
github of something discussed in Jira. Really bad to have someone look at
an issue, think they have the full picture and be missing 1/3 of the
discussion.

So principles I'd like to advocate are:
1) Don't break links to Jiras
2) Single source of truth for any individual issue.
3) Optionally for user convenience reflect the source of truth for old
issues in github as read only, with a back reference.

On Wed, Jun 15, 2022 at 11:56 AM Michael McCandless <
lucene@mikemccandless.com> wrote:

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


--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

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

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

Tomoko

2022?6?16?(?) 0:56 Michael McCandless <lucene@mikemccandless.com>:

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

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

> Totally agree. The history of closed issues answer “when did this change
> and why?”. Migrate them all. Computers can do that. It avoids asking humans
> to think about where stuff is.
>

We do have different views of that. To me, the history is preserved
perfectly well in Jira, it's not being phased out. Moving to github as the
issue tracking system is fine but different to me than code transitions
(cvs->svn->git). With code, you do have an existing state and history
you build from. With issue tickets - not so much. And even if you want to
create a ticket in the new system, you can easily link to the previous one.
It's the "web" of hyperlinks, right?

I'm a bit afraid that moving hundreds of jira issues to github will have
the reverse effect - duplicate the same information but with quality
degraded, for example automatic links that work in Jira will no longer work
or point at the ported github issues ("this is related to LUCENE-xyz or
SOLR-abc, blah, blah blah.")?

I don't want to stand in the way of progress but we've gone through a
similar transition at our company and I never had a problem using both
systems at the same time; jira just gradually atrophied into a read-only
state once issues in there got stale or resolved.

Dawid

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

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

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

Thank you,
Tomoko

2022?6?16?(?) 4:18 Dawid Weiss <dawid.weiss@gmail.com>:

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

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

I'm not a fan of the automated copying of any issues into GitHub, which
will create a divergence / duplicity of an issue's identity. It will only
be a relatively temporary annoyance to have two systems to "work" on an
issue. Eventually, JIRA will only be historical; let's say Lucene 11. At
that point if there's an older issue of resumed interest, which would be
getting increasingly rare, someone could manually copy the original
description and title into GitHub plus a historical reference back. Again
-- rare by then.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Jun 15, 2022 at 4:18 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> It looks like we talked about two or three things at the same time -
> and I'm afraid the discussion will quickly turn into a disordered
> state and I won't be able to track it.
>
> Let me decide one thing: Let's NOT try to move histories to GitHub.
> Closed issues will remain in Jira forever and we can refer to them
> anytime from anywhere. I think I said that before several times.
>
> I would like to focus on the future here - can we make a decision on
> how to handle active (unresolved) issues and issues that will be
> opened in the future.
>
> Thank you,
> Tomoko
>
> 2022?6?16?(?) 4:18 Dawid Weiss <dawid.weiss@gmail.com>:
>
> >
> >
> >> Totally agree. The history of closed issues answer “when did this
> change and why?”. Migrate them all. Computers can do that. It avoids asking
> humans to think about where stuff is.
> >
> >
> > We do have different views of that. To me, the history is preserved
> perfectly well in Jira, it's not being phased out. Moving to github as the
> issue tracking system is fine but different to me than code transitions
> (cvs->svn->git). With code, you do have an existing state and history you
> build from. With issue tickets - not so much. And even if you want to
> create a ticket in the new system, you can easily link to the previous one.
> It's the "web" of hyperlinks, right?
> >
> > I'm a bit afraid that moving hundreds of jira issues to github will have
> the reverse effect - duplicate the same information but with quality
> degraded, for example automatic links that work in Jira will no longer work
> or point at the ported github issues ("this is related to LUCENE-xyz or
> SOLR-abc, blah, blah blah.")?
> >
> > I don't want to stand in the way of progress but we've gone through a
> similar transition at our company and I never had a problem using both
> systems at the same time; jira just gradually atrophied into a read-only
> state once issues in there got stale or resolved.
> >
> > Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

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

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

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

Is there anyone who strongly opposes this?

Tomoko

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

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

+1 to your suggestion.

On Thu, Jun 16, 2022 at 12:34 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

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

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Hi Tomoko,


> * All new issues should be opened on GitHub. Opening new Jira issues
> is discouraged unless there is a good reason.
>

I'm fine with this. New issues from contributors who are not aware of the
migration can be immediately
cloned to github and closed in Jira as well (vide Adrien's previous
suggestion to make an explicit template in
Jira to point people in the right direction). The "discouragement" would
then probably apply only to those folks who
expressed their negative sentiments against github (and don't have an
account there, for example).


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

I'm also fine with this. Again - allows for a gradual transition without
extra effort for you. My experience tells me such
transition will be a pretty rapid process anyway. If you take a look at how
fast it was to switch to pull requests vs.
patch-in-jira, it's likely to follow the same kind of pattern.

Dawid

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

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

Tomoko

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

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

I thinking proposing the way to deal with versions and all "labels"
applying to issues is an important part of the work remaining. I know
you've outlined the way different projects handle this, Tomoko. I can't
really offer my suggestions here - I've dealt with both types (milestones
and labels) and they're equally clumsy at times. :)

D.

On Fri, Jun 17, 2022 at 5:20 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> > I see you already have a start at the migration plan, yay! (The comment
> on LUCENE-10557)
> > Could we maybe pull that out into a wiki page so we can more easily
> collaborate on the steps?
>
> There would not be so many topics that are controversial except for
> the current discussion about existing Jira issues, and I think we are
> close to reaching a conclusion.
> I re-summarized the migration steps and tasks to be done in the issue
> description and I will update it when there is progress. (Most of the
> remaining work is an administrative job.)
>
> Tomoko
>
> 2022?6?16?(?) 17:13 Dawid Weiss <dawid.weiss@gmail.com>:
> >
> >
> > Hi Tomoko,
> >
> >>
> >> * All new issues should be opened on GitHub. Opening new Jira issues
> >> is discouraged unless there is a good reason.
> >
> >
> > I'm fine with this. New issues from contributors who are not aware of
> the migration can be immediately
> > cloned to github and closed in Jira as well (vide Adrien's previous
> suggestion to make an explicit template in
> > Jira to point people in the right direction). The "discouragement" would
> then probably apply only to those folks who
> > expressed their negative sentiments against github (and don't have an
> account there, for example).
> >
> >>
> >> * All existing issues should be resolved in Jira. Copying or moving
> >> Jira issues to GitHub is discouraged unless there is a good reason.
> >
> >
> > I'm also fine with this. Again - allows for a gradual transition without
> extra effort for you. My experience tells me such
> > transition will be a pretty rapid process anyway. If you take a look at
> how fast it was to switch to pull requests vs.
> > patch-in-jira, it's likely to follow the same kind of pattern.
> >
> > Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Hello, sorry, I'm still trying to catch up here, and getting on an airplane
soon, yet I'm unhappy at how this thread is going ;)

> Again - allows for a gradual transition without extra effort for you.

I would not ask/expect Tomoko to do this migration. If that really is
influencing people's minds here, I volunteer to try to create/iterate the
tool that can migrate Jira issues to GitHub, if we can agree that keeping
our full history is worthwhile/important.

So far it looks like I'm one of maybe only two devs passionately against
throwing away the rich history in our issue tracker. Maybe it is because I
am too old and have come to value history too much ;)

Say two years from now we want to migrate to XYZ issue tracker. Would we
choose again to discard past issues (Jira and GitHub issues)? Expect
future devs to learn three issue trackers if they want to understand
Lucene's rich history? How would such users search across three issues
trackers? Or maybe you believe there will never be another issue tracker
better than GitHub issues in the whole future of our development ;)

We are setting a precedent here, and I think it's bad to say "we discard
our history on migrating to the latest issue tracker". We should not rush
this decision, and again, if volunteering is the problem, I volunteer to
find a way forward.

> Is there anyone who strongly opposes this?

I'm sorry but I still do.

Having two writable issue trackers seems like a recipe for disaster, both
short term and long term. Short term: we are relying on good/best
intentions of a distributed dev community, instead of a mechanism that
would ensure we don't mess up (sorry, a very Amazonian reference:
https://www.factoftheday1.com/p/september-7-good-mechanisms-outperform).
Are we able to at least block the creation of new issues in Jira going
forward, and redirect that to GitHub issues instead? Long term: new future
devs won't know how to use Jira. It will be "that old system devs used to
use but we don't ever look at". They won't know to go to another search
engine to find issues there. They won't subscribe to the lists to see
comments from users saying "hey, I hit this issue, I tried the workaround
here, it didn't work", etc.

This kills me: when new devs search for issues using GitHub, they'll only
find the "new" ones, not the Jira ones. They won't know that the big
missing issues from Jira every happened. Search determines truth in our
issue trackers.

Also, say a user adds a comment to a closed Jira issue, saying "this bit
me, in version XYZ, but I thought it was fixed?". Only devs who subscribe
to updates for the "legacy" Jira will even see that response. Why risk
that division?

We must optimize for the long-term health of our development community, not
for the short-term pain of already expert Jira users. Community over code.

> I'm not a fan of the automated copying of any issues into GitHub, which
will create a divergence / duplicity of an issue's identity.

I think this is optimizing for the wrong thing (the pain of we expert Jira
users). We should rather optimize for the future developers who replace us
and will have zero familiarity with Jira. Also, on moving all Jira issues
to GitHub, we can insert at the top of the issue's o.p. the link to the
"legacy" Jira issue.

Rather, I see the divergence as the opposite: leaving some issues in Jira
and new issues in GitHub is painful divergence tax going forwards. To old
timers and new developers, Lucene would still have one issue tracker
holding all issues, if we carry all issues forward to GitHub.

> At that point if there's an older issue of resumed interest, which would
be getting increasingly rare, someone could manually copy the original
description and title into GitHub plus a historical reference back. Again
-- rare by then.

I don't think this is a rare case.

Lucene's rich history is vital, because we are such a long running yet
still vibrant open-source community.

Say you want to understand why Lucene's file locking works the crazy way it
does today? Why does IndexWriter make assertions about locks? Why don't
locks typically work on NFS, and you must then use a custom
IndexDeletionPolicy? Or why did we move responsibility of retrying
deletions from IW to FSDirectory? Or how about why copyBytes allocates new
byte arrays instead of reusing? The source control record only contains
trivial summaries (often/typically squashed on merge into main, removing
perhaps interesting specifics of individual local commits too) of what was
a very passionate and tricky debate at the time, captured in our issue
tracker.

> There would not be so many topics that are controversial except for the
current discussion about existing Jira issues, and I think we are close to
reaching a conclusion.

I think it's premature to say this. I have not yet studied the problem
closely, but GitHub issues is indeed quite different from Jira's
schema/workflow. We should not rush this -- let's propose the migration
and all look at it / make suggestions. Dawid already had a good thing to
consider (milestones vs labels).

> They are inevitably in conflict with each other - it looks like many
folks put more weight on 1 than 2, then I would go with it.

I don't think this is a real conflict. If we migrate every Jira issue to
GitHub, each of those, and newly created issues, still have a strong
identity in a single issue tracker. We can link back to the "legacy issue
tracker" in each Jira -> GitHub migrated issue.

> I'm a bit afraid that moving hundreds of jira issues to github will have
the reverse effect - duplicate the same information but with quality
degraded, for example automatic links that work in Jira will no longer work
or point at the ported github issues ("this is related to LUCENE-xyz or
SOLR-abc, blah, blah blah.")?

I agree the embedded links are tricky. Not sure whether we could do a big
rewrite of those links or not ... seems a chicken/egg situation. We could
1) append a forwarding link comment on the Jira issue to its GitHub
version, and 2) make Jira read-only so the risk of a user adding a Jira
comment on an old issue that then goes into /dev/null, is gone.

Sorry for the long passionate rant :) It just drives me crazy that so many
of us are choosing to discard our history. Saying "I can always find the
issue in Jira" is vacuous -- future Lucene devs won't know how to search in
Jira, how to subscribe to Jira updates, etc. We need to optimize for the
long-term health of our community, making it easy for new future devs to
discover the rich history of why certain decisions were made. If we throw
away that history we do the opposite. And once (not if, once) we migrate
issue trackers again, we need to set a precedent that we don't then expect
future devs to learn N+1 issue trackers for searching history.

Mike McCandless

http://blog.mikemccandless.com

On Fri, Jun 17, 2022 at 2:20 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:

>
> I thinking proposing the way to deal with versions and all "labels"
> applying to issues is an important part of the work remaining. I know
> you've outlined the way different projects handle this, Tomoko. I can't
> really offer my suggestions here - I've dealt with both types (milestones
> and labels) and they're equally clumsy at times. :)
>
> D.
>
> On Fri, Jun 17, 2022 at 5:20 AM Tomoko Uchida <
> tomoko.uchida.1111@gmail.com> wrote:
>
>> > I see you already have a start at the migration plan, yay! (The
>> comment on LUCENE-10557)
>> > Could we maybe pull that out into a wiki page so we can more easily
>> collaborate on the steps?
>>
>> There would not be so many topics that are controversial except for
>> the current discussion about existing Jira issues, and I think we are
>> close to reaching a conclusion.
>> I re-summarized the migration steps and tasks to be done in the issue
>> description and I will update it when there is progress. (Most of the
>> remaining work is an administrative job.)
>>
>> Tomoko
>>
>> 2022?6?16?(?) 17:13 Dawid Weiss <dawid.weiss@gmail.com>:
>> >
>> >
>> > Hi Tomoko,
>> >
>> >>
>> >> * All new issues should be opened on GitHub. Opening new Jira issues
>> >> is discouraged unless there is a good reason.
>> >
>> >
>> > I'm fine with this. New issues from contributors who are not aware of
>> the migration can be immediately
>> > cloned to github and closed in Jira as well (vide Adrien's previous
>> suggestion to make an explicit template in
>> > Jira to point people in the right direction). The "discouragement"
>> would then probably apply only to those folks who
>> > expressed their negative sentiments against github (and don't have an
>> account there, for example).
>> >
>> >>
>> >> * All existing issues should be resolved in Jira. Copying or moving
>> >> Jira issues to GitHub is discouraged unless there is a good reason.
>> >
>> >
>> > I'm also fine with this. Again - allows for a gradual transition
>> without extra effort for you. My experience tells me such
>> > transition will be a pretty rapid process anyway. If you take a look at
>> how fast it was to switch to pull requests vs.
>> > patch-in-jira, it's likely to follow the same kind of pattern.
>> >
>> > Dawid
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

On Fri, Jun 17, 2022 at 12:08 PM Michael McCandless
<lucene@mikemccandless.com> wrote:
>
> I agree the embedded links are tricky. Not sure whether we could do a big rewrite of those links or not ... seems a chicken/egg situation. We could 1) append a forwarding link comment on the Jira issue to its GitHub version, and 2) make Jira read-only so the risk of a user adding a Jira comment on an old issue that then goes into /dev/null, is gone.
>

Couldn't we solve this with 2 passes?

First pass: create GH issue corresponding to each JIRA issue:
LUCENE-1000 -> issue #564
Second pass: "correct" references in the texts: LUCENE-1000 -> #564

You could also handle special "links" in JIRA issues with the same
stuff, e.g. at the beginning of the GH issue, it could just have some
markdown like:
Links:
* Relates to #476

Could also be a way to transfer over subtasks with some sanity, e.g.
add "Subtask of #200" to the text somewhere. Then these would be
"linked" in GH.

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

> I would not ask/expect Tomoko to do this migration. If that really is
> influencing people's minds here, I volunteer to try to create/iterate the
> tool that can migrate Jira issues to GitHub, if we can agree that keeping
> our full history is worthwhile/important.
>

Ahem... You're right. It wasn't my intention to put the heavy burden on
Tomoko, sorry.


> So far it looks like I'm one of maybe only two devs passionately against
> throwing away the rich history in our issue tracker.
>

This is the bit we clearly have a different opinion on - I don't have a
problem with part of the history staying in Jira. I do accept your argument
about searching through history using one user interface though - this
indeed would be useful.


> Maybe it is because I am too old and have come to value history too much ;)
>

This is overdramatic. It'd be different if Jira were to be removed but it's
not - it's staying. There are a million links around the web pointing at
those Jira issues. Blogs, code, etc. If you create a copy in github and
people start commenting on those issues in github then those links point at
a stale state... So not only we'd need a link from github to jira... we'd
also need a link from jira to the (new) github issue and a freeze on any
changes in Jira after that.


> Say two years from now we want to migrate to XYZ issue tracker. Would we
> choose again to discard past issues (Jira and GitHub issues)?
>

I'd be more afraid of what happens to github issues in two years (or
longer). Will it look the same? Will it be different? Will it be gone (and
how do we get a backup of the isse history then)? Contrary to the
apache-hosted Jira, github is very much an independent entity. If Elon Musk
decides to buy and close it tomorrow... then what? :)

Dawid

On Fri, Jun 17, 2022 at 3:27 PM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>
> I'd be more afraid of what happens to github issues in two years (or longer). Will it look the same? Will it be different? Will it be gone (and how do we get a backup of the isse history then)? Contrary to the apache-hosted Jira, github is very much an independent entity. If Elon Musk decides to buy and close it tomorrow... then what? :)
>

We already have a ton of github "issues" (pull requests, since PRs are issues).
If you want to "back them up", its easy, you can paginate thru them
100 at a time, e.g. run this command, incrementing 'page' until it
returns empty list:

curl -H "Accept: application/vnd.github.v3+json"
"https://api.github.com/repos/apache/lucene/issues?per_page=100&page=1&direction=asc&state=all"
> file1.json

Yeah of course if you want to backup the comments and stuff, you'll
need to do more.
But it is already the case today, that a ton of this "history" is
already in github issues, as PRs. Most recent JIRAs are just useless
placeholders.
Also the same risks apply to JIRA, except are not theoretical and real
concerns, no? I thought Atlassian had deprecated "onsite" JIRA to try
to sucker you into their "Atlassian Cloud":
https://www.theregister.com/2020/10/19/atlassian_server_licenses/

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

I hope you count me as someone who sees history as important. It's
important in more ways than one however. You gave the example of trying to
understand something, and looking at the issue history directly. I also
give weight to the scenario where someone has written a blog post about the
topic and linked the issue "For the latest see LUCENE-XXXX" for example...
Or someone planning upgrades has a spreadsheet of things to track down...
The existing links should point to a *complete* history of the issue.

I don't see the migration of everything to github as being as critical as
you do but I'm not at all against migrating things that are closed if
someone wants to do that work, and perhaps even copying over existing open
issues periodically as they become closed (and accelerating the close rate
by aggressive closing of silent issues). No new issues in Jira sounds
fine, even better if enforced by Jira. Proceed from here in Github since
that's where the community wants to go. Links to the migrated version
automatically added to Jira and/or backlinks to Jira would be just fine too
since readers might (hopefully needlessly) worry that something didn't get
migrated, we should make it easy to check.

What I don't want is for someone to land on an issue via link or via google
search (or via search in jira because they are using Jira already for some
other apache project), read through it and think A) it never got resolved
when it did or B) miss the fact that it got reopened and further changes
were made and only have half the story... or any other scenario where they
are looking at an incomplete record of the issue. (thus
obfuscating/splitting the very important rich history across systems).

So that's why I feel issues should be completely tracked in the system
where they were created. Syncing old closed stuff into a new system
probably is fine so long as there are periodic sweeps to pull in reopens or
newly completed issues. We could even sync open things so long as they are
clearly marked in the title as having their primary record in Jira and
"last synced from JIRA on YYYY-MM-DD" or something in a final comment each
time new content is brought over.

For simplicity and workload however maybe just sync things when they close.
Depends on how much effort the person writing code for syncing things wants
to put into it I guess.

Although I agree with Dawid on the "What if Elon buys it?" issue, that ship
has sailed, the community accepts that risk and we probably should not
rehash it.

WRT Robert's comments on PRs being issues... this has already worried me
because I've already seen a lot of discussion on PR's and I've worried that
this stuff has the potential to get lost or be hard to find. If there is
one key positive of this move is that they will become easier to find since
the search in github can find it. I would say that a PR is not a substitute
for a well described issue report but that's probably a separate discussion
(which I would hope mirrors the policy on small edits like typos or adding
comments/javadoc not needing an issue). I've also seen folks who like to
clean up and remove old branches and PR's, which is problematic if that's
where the important discussion is (possibly a 3rd can of worms there).

-Gus

On Fri, Jun 17, 2022 at 4:34 PM Robert Muir <rcmuir@gmail.com> wrote:

> On Fri, Jun 17, 2022 at 3:27 PM Dawid Weiss <dawid.weiss@gmail.com> wrote:
> >
> > I'd be more afraid of what happens to github issues in two years (or
> longer). Will it look the same? Will it be different? Will it be gone (and
> how do we get a backup of the isse history then)? Contrary to the
> apache-hosted Jira, github is very much an independent entity. If Elon Musk
> decides to buy and close it tomorrow... then what? :)
> >
>
> We already have a ton of github "issues" (pull requests, since PRs are
> issues).
> If you want to "back them up", its easy, you can paginate thru them
> 100 at a time, e.g. run this command, incrementing 'page' until it
> returns empty list:
>
> curl -H "Accept: application/vnd.github.v3+json"
> "
> https://api.github.com/repos/apache/lucene/issues?per_page=100&page=1&direction=asc&state=all
> "
> > file1.json
>
> Yeah of course if you want to backup the comments and stuff, you'll
> need to do more.
> But it is already the case today, that a ton of this "history" is
> already in github issues, as PRs. Most recent JIRAs are just useless
> placeholders.
> Also the same risks apply to JIRA, except are not theoretical and real
> concerns, no? I thought Atlassian had deprecated "onsite" JIRA to try
> to sucker you into their "Atlassian Cloud":
> https://www.theregister.com/2020/10/19/atlassian_server_licenses/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)