I don't intend to neglect histories in Jira... it's an important,
valuable asset for all of us and possible contributors in the future.
It's important, *therefore*, I don't want to have the degraded copies
of them on GitHub.
We cannot preserve all of history - again, there should be tons of
unignorable information losses (timestamp, reporter, assignee,
markdown, metadata that cannot be ported to GitHub) if we attempt to
migrate the whole Jira history into Github. Rather than trying to have
such incomplete copies, I would preserve Jira issues in the perfectly
archived status, then simply refer to them.
Tomoko
2022?6?18?(?) 7:47 Gus Heck <gus.heck@gmail.com>:
>
> 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
valuable asset for all of us and possible contributors in the future.
It's important, *therefore*, I don't want to have the degraded copies
of them on GitHub.
We cannot preserve all of history - again, there should be tons of
unignorable information losses (timestamp, reporter, assignee,
markdown, metadata that cannot be ported to GitHub) if we attempt to
migrate the whole Jira history into Github. Rather than trying to have
such incomplete copies, I would preserve Jira issues in the perfectly
archived status, then simply refer to them.
Tomoko
2022?6?18?(?) 7:47 Gus Heck <gus.heck@gmail.com>:
>
> 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org