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.
>> >>>
>> >>
>>

Reply via email to