On Wed, Mar 7, 2018 at 11:17 AM, Mike Walch <mwa...@apache.org> wrote: >> >> 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. >> > > My view is that issues do not have to be worked on to be moved. If someone > thinks an issue is important, > they can move it over, create links both ways, and close the JIRA issue.
SGTM > > On Wed, Mar 7, 2018 at 10:55 AM, Keith Turner <ke...@deenlo.com> 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. >> >>> >> >> >>
