Sorry for the top-post.

I really appreciate the numbered list below, Keith. Specifically the answers to #1 and #4 make me very happy.

I think #5 needs some a little more concrete (IMO, you should just decide what it should be).

#6 +1 to a message to private, this is how Apache general requests this be done).

While I can appreciate your stance on #3 and I think I would not call it a blocker either, this is probably something worth the 15-30 minutes of investigation. Sean/Mike may feel more strongly than I do. Learning from others, even if it just dropping an email to dev@spark directly to ask the question goes a long way..

On 3/7/18 10:55 AM, Keith Turner wrote:
On Mon, Mar 5, 2018 at 6:07 PM, Keith Turner <> wrote:
On Thu, Feb 15, 2018 at 12:52 PM, Josh Elser <> wrote:
-0 as an initial reaction because I'm still not convinced that GH issues
provides any additional features or better experience than JIRA does, and
this change would only serve to fragment an already bare community.

My concerns that would push that -0 to a -1 include (but aren't limited to):

* Documentation/website update for the release process
* Validation that our release processes on JIRA has similar functionality on
GH issues
* Updated contributor docs (removing JIRA related content, add an
explanation as to the change)
* updated on relevant repos

I opened the following PR with a proposal for how we could start using github.

There were lots of valid concerns raised during this discussion.  The
concerns shaped the proposal I submitted. Rather than reply to them
individually in different emails I am collecting them all here and
sharing my thoughts about them.

1. How do we release?

   JIRA is used in three important ways for releases : setting blockers,
   triaging issues, and generating release notes.  I think the proposal
   addresses all three.

2. Will we document contributor guidelines to avoid confusion?

   What is expected of contributors is clearly documented.

3. Can someone investigate how Spark operates before switching?

   That would be great if someone volunteered to do this and wrote up their
   findings.  However if no one volunteers, then I do not think this should
   be a blocker.  There are many other projects that would be worthy of
   investigation also.

4. What is the migration plan for existing issues?  Will we have split issue
    tracker for years?

   The proposal documents migrating existing JIRA issues as they are worked.
   This means that existing JIRA issues that are never worked will never
   migrate. After all branches are released, JIRA can be put in read only mode
   (only PMC can change it).  It will be left active for reference and
   migration of existing issues.

5. How will we handle fix versions?

    The proposal suggest using issue labels in github for this.  Also suggest
    using a prefix on fix version labels to make them sort last.

6. How will we handle security issues?

    We need to clearly document on our website how users should report
    security issues.  I am not sure this is done at the moment.  Since this
    is infrequent I think we can handle this on the private list.  I think
    our workflow should be optimized for frequent actions and not infrequent

7. Should we switch all repos to GH issues except Accumulo core?

    I think this a good example of how design by committee can go
    wrong.  This is a really confusing solution that does not
    improve our workflow, so the benefits are not clear to me.

- Josh

On 2/15/18 12:05 PM, Mike Walch wrote:

I would like to open discussion on moving from Jira to GitHub issues.
GitHub issues would be enabled for a trial period. After this trial
the project would either move completely to GitHub issues or keep using
Jira. Two issue trackers would not be used after trial period.

Reply via email to