You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Tomoko Uchida (Jira)" <ji...@apache.org> on 2022/06/20 05:12:00 UTC

[jira] [Comment Edited] (LUCENE-10557) Migrate to GitHub issue from Jira

    [ https://issues.apache.org/jira/browse/LUCENE-10557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556188#comment-17556188 ] 

Tomoko Uchida edited comment on LUCENE-10557 at 6/20/22 5:11 AM:
-----------------------------------------------------------------

For version control, there are two considerations.

1. Fix Version(s)

We have two options: Milestone or Label. One important difference between them is that an issue can have only one milestone but multiple labels. The other difference would be that while Milestone is special metadata, labels are just flexible text tags for searching. I'm personally fine with Milestone - we don't release a bug fix or improvement in multiple versions anyway. We don't have two CHANGES entries for one issue; if we resolve an issue in "10.0.0" and "9.3.0" the CHANGES entry appears only in Lucene 9.3.0's section. 
If there are other perspectives, would you share your thoughts on it.

2. Affects Version(s)

35% of unresolved issues have this field. Maybe we could have issue labels such as "affectsVersion:9.3.0". I have never used this metadata field and I myself have no problem with omitting this in GitHub. Is there anyone who has thoughts on it?

-- 
Aside from versions, I'm not fully sure about how to port the "Priority" field (Blocker, Critical, Major, Minor, Trivial). It's a mandatory field in Jira but there seem no clear standards on how to set a priority except for "Blocker". Should we have this also in GitHub as a mandatory label, or should we have this as an optional one, or perhaps can we omit this in GitHub if developers/committers don't really take care of this?

 


was (Author: tomoko uchida):
For version control, there are two considerations.

1. Fix Version(s)

We have two options: Milestone or Label. One important difference between them is that an issue can have only one milestone but multiple labels. The other difference would be that while Milestone is special metadata, labels are just flexible text tags for searching. I'm personally fine with Milestone - we don't release a bug fix or improvement in multiple versions anyway. We don't have two CHANGES entries for one issue; if we resolve an issue in "10.0.0" and "9.3.0" the CHANGES entry appears only in Lucene 9.3.0's section. 
If there are other perspectives, would you share your thoughts on it.

2. Affects Version(s)

45% of unresolved issues have this field. Maybe we could have issue labels such as "affectsVersion:9.3.0". I have never used this metadata field and I myself have no problem with omitting this in GitHub. Is there anyone who has thoughts on it?

-- 
Aside from versions, I'm not fully sure about how to port the "Priority" field (Blocker, Critical, Major, Minor, Trivial). It's a mandatory field in Jira but there seem no clear standards on how to set a priority except for "Blocker". Should we have this also in GitHub as a mandatory label, or should we have this as an optional one, or perhaps can we omit this in GitHub if developers/committers don't really take care of this?

 

> Migrate to GitHub issue from Jira
> ---------------------------------
>
>                 Key: LUCENE-10557
>                 URL: https://issues.apache.org/jira/browse/LUCENE-10557
>             Project: Lucene - Core
>          Issue Type: Sub-task
>            Reporter: Tomoko Uchida
>            Assignee: Tomoko Uchida
>            Priority: Major
>
> A few (not the majority) Apache projects already use the GitHub issue instead of Jira. For example,
> Airflow: [https://github.com/apache/airflow/issues]
> BookKeeper: [https://github.com/apache/bookkeeper/issues]
> So I think it'd be technically possible that we move to GitHub issue. I have little knowledge of how to proceed with it, I'd like to discuss whether we should migrate to it, and if so, how to smoothly handle the migration.
> The major tasks would be:
>  * (/) Get a consensus about the migration among committers
>  * Choose issues that should be moved to GitHub
>  ** Discussion thread [https://lists.apache.org/thread/1p3p90k5c0d4othd2ct7nj14bkrxkr12]
>  ** -Conclusion for now: We don't migrate any issues. Only new issues should be opened on GitHub.-
>  ** Write a prototype migration script - the decision could be made on that. Things to consider:
>  *** version numbers - labels or milestones?
>  *** add a comment/ prepend a link to the source Jira issue on github side,
>  *** add a comment/ prepend a link on the jira side to the new issue on github side (for people who access jira from blogs, mailing list archives and other sources that will have stale links),
>  *** convert cross-issue automatic links in comments/ descriptions (as suggested by Robert),
>  *** strategy to deal with sub-issues (hierarchies),
>  *** maybe prefix (or postfix) the issue title on github side with the original LUCENE-XYZ key so that it is easier to search for a particular issue there?
>  *** how to deal with user IDs (author, reporter, commenters)? Do they have to be github users? Will information about people not registered on github be lost?
>  *** create an extra mapping file of old-issue-new-issue URLs for any potential future uses. 
>  *** what to do with issue numbers in git/svn commits? These could be rewritten but it'd change the entire git history tree - I don't think this is practical, while doable.
>  * Build the convention for issue label/milestone management
>  ** Do some experiments on a sandbox repository [https://github.com/mocobeta/sandbox-lucene-10557]
>  ** Make documentation for metadata (label/milestone) management 
>  * Enable Github issue on the lucene's repository
>  ** Raise an issue on INFRA
>  ** (Create an issue-only private repository for sensitive issues if it's needed and allowed)
>  ** Set a mail hook to [issues@lucene.apache.org|mailto:issues@lucene.apache.org] (many thanks to the general mail group name)
>  * Set a schedule for migration
>  ** Give some time to committers to play around with issues/labels/milestones before the actual migration
>  ** Make an announcement on the mail lists
>  ** Show some text messages when opening a new Jira issue (in issue template?)



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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