[
https://issues.apache.org/jira/browse/SPARK-55017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18051613#comment-18051613
]
Yicong Huang commented on SPARK-55017:
--------------------------------------
I am supporting this idea! From my experience I prefer to use GitHub issues
over JIRA tickets.
A few clarification questions:
1. Do we have to migrate all existing, archived/historical JIRA tickets to
GitHub? Alternatively we could only do it for new tickets right? The steps
would be easier: making JIRA readonly and let developers create GH issues;
during transition developers can link either JIRA ticket or GH issue;
eventually all new PRs will link to GH issues and JIRA gradually phase out.
2. GitHub issues (in Apache namespace) has issue subtypes of "Bug", "Feature"
and "Task". It is by no means as powerful as JIRA, but is that sufficient
enough (possibly with other tags)?
3. Currently the ticket handler is in the format of `SPARK-xxx`. If we do GH
issues it will be `GH-XXX`. I see one problem is how do we differentiate this
handle when referencing from other projects/systems? I know GitHub supports
`apache/spark#xxx` to do cross-repo reference. But it would be quite verbose.
> SPIP: Migrate from JIRA to Github issues
> ----------------------------------------
>
> Key: SPARK-55017
> URL: https://issues.apache.org/jira/browse/SPARK-55017
> Project: Spark
> Issue Type: Umbrella
> Components: Project Infra
> Affects Versions: 4.2.0
> Reporter: Tian Gao
> Priority: Major
>
> *Q1.* What are you trying to do? Articulate your objectives using absolutely
> no jargon.
> I propose to migrate from our current JIRA system to Github issues. All the
> existing tickets will be transferred to github issues and the current JIRA
> will be read-only and archived.
> *Q2.* What problem is this proposal NOT designed to solve?
> The usage of other github features, for example, allowing using github UI to
> merge instead of using a merge script.
> *Q3.* How is it done today, and what are the limits of current practice?
> We are currently using JIRA, and we have some issues.
> # The bar is too high for new contributors to involve in spark's development
> because
> ** They can't register an account without a PMC's explicit confirmation
> ** They are not familiar with how JIRA works
> ** They don't even know JIRA exists, they are only familiar with github
> issues
> # Discussions on tickets are limited because people don't switch between
> websites (and of course, new comers can't comment)
> # We are missing feedbacks from the community because it's not easy for them
> to report issues.
> *Q4.* What is new in your approach and why do you think it will be successful?
> I propose that we use native github issues, which is the single mostly used
> ticket system in the software world. We are using github to host our repos,
> to do PRs (mostly) and to run CIs already - adding issues to the list should
> be very intuitive.
> Also, a lot of Apache projects are moving to github issues. Arrow for
> example. [https://github.com/apache/arrow/issues/14542] . Lucene, Beam and
> many other projects are also on the list. I have not seen a project that went
> the other direction. Github issues are also in active development and is
> becoming better.
> *Q5.* Who cares? If you are successful, what difference will it make?
> I think most importantly, people who don't own a JIRA account cares. This
> might not be too critical for our regular committers, but it will benefit the
> users and new contributors a lot. The first time I tried to contribute to
> spark, I was scared away because of the JIRA ticket system.
> If we take a look at our existing tickets, they are mostly placeholders for
> tasks that committers plan to do - but for most active open source projects,
> it should be feedbacks (bug reports, feature requests, etc.) from the
> community. This is because of the artificial bar we have for the community.
> *Q6.* What are the risks?
> Migration is not risk-free, I'll list all the issue I can think of.
> * Migration itself takes time and effort. There could be some disruption
> during the migration
> * We can't "duplicate" a JIRA system. Github issues is different. For example
> ** it does not have native "types" for each issue - it uses tags to
> categorize issues.
> ** it has sub-issue system, but might not be as polished as JIRA
> ** it lacks many fields JIRA has, like fixed-version or component, they all
> need to be done with tags.
> ** it does not have "OrderBy" feature
> * Even though we will migrate all JIRA tickets to github, we will miss some
> information that is not easily migrated.
> * We need to rewrite some bots for github issues
> *Q7.* How long will it take?
> I think it will take about 1-2 months.
> # Create an issue template, then open issues tab. (< 1w)
> # Start working on equivalent bots to link github PRs to github issues.
> During this time, committers still work on JIRA. (~1w)
> # Allow work on github issues, while keeping JIRA available - this phase is
> to test the github bots and see if we have any issues with the new system.
> (2w - can be extended if we don't feel ready)
> # Convert JIRA to read-only mode, migrate all Jira tickets to github (there
> are scripts for this, used by arrow/beam, should not be too hard). (1-2w).
> # Observe how people work on the new system. If we have major issues, we can
> revert back to JIRA. (We consider this project done at this phase)
> # Remove the JIRA bot when everything is stable.
> *Q8.* What are the mid-term and final “exams” to check for success?
> mid-term success is that people can work with github issues regularly. We
> have set up all the necessary tools for github issues. If we heard few to
> none complaints from committers, that's good.
> final success is that we fully migrate to github issues and JIRA is not being
> used. More importantly, I expect us to see much more feedback from the
> community. I think we should see a significantly increase in number of issues
> from the community (other than committers) - that would be the real final
> goal for this proposal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
