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 <ke...@deenlo.com> wrote:
On Thu, Feb 15, 2018 at 12:52 PM, Josh Elser <els...@apache.org> 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)
* CONTRIBUTING.md updated on relevant repos
I opened the following PR with a proposal for how we could start using github.
https://github.com/apache/accumulo-website/pull/59
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
ones.
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
period,
the project would either move completely to GitHub issues or keep using
Jira. Two issue trackers would not be used after trial period.
