I agree that "discussion" will be done on mailing lists (as always).
Properly speaking, stopping using Jira means "we don't accept patch style
contributions anymore".
GitHub doesn't allow ".patch" files as attachments; it'd be reasonable for
GitHub.
https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/attaching-files

I'm not sure if it has a substantial effect and I myself am fine with that
- just wanted to clarify what we are going to discard.

Tomoko


2022年7月17日(日) 23:40 Michael Sokolov <msoko...@gmail.com>:

> I think we'd still have the mailing lists open for discussion. So anyone
> not willing or able to use GitHub would still be able to participate in a
> meaningful way. Having two parallel bug trackers seems much less useful to
> me. I'd rather have people emailing to a list that is active rather than
> posting comments to a repository that we may very likely start to ignore.
>
> On Sun, Jul 17, 2022, 10:09 AM Tomoko Uchida <tomoko.uchida.1...@gmail.com>
> wrote:
>
>> Thank you Mike for opening the discussion.
>>
>> I don't really have a clear "opinion" on that, but I just wanted to try
>> to explain my perspective.
>>
>> Today almost all development is already going on GitHub pull requests,
>> then it would be a natural direction for the majority of devs to move our
>> primary conversation platform to GitHub. I think we should try to optimize
>> our environment for majorities, although I know we will never be able to
>> reach a unanimous agreement.
>> Meanwhile, it was not my intention to completely discontinue the
>> contribution path via Jira. I rather optimistically thought we could leave
>> room for developers who don't use GitHub for any reason.
>>
>> As for preventing someone from "accidentally" opening Jira issues, we
>> could show a text that says "Jira has been deprecated. Please open GitHub
>> issue unless you are not able to do so." when he/she is attempting to open
>> Jira.
>>
>> https://confluence.atlassian.com/adminjiraserver/configuring-contexts-and-default-values-for-the-description-field-1047552727.html
>>
>> I agree that it'd be the cleanest way to make Jira read-only and I myself
>> am fine with the proposal - maybe I'm overthinking.
>>
>> Tomoko
>>
>>
>> 2022年7月17日(日) 22:13 Michael McCandless <luc...@mikemccandless.com>:
>>
>>> Hi Team,
>>>
>>> Thanks to Tomoko's amazing hard work (
>>> https://github.com/apache/lucene-jira-archive), we are getting close to
>>> having strong tooling and a solid plan to migrate all past Jira issues to
>>> GItHub issues!
>>>
>>> But one contentious point is whether to leave Jira read-only or
>>> read-write after the migration.  So let's DISCUSS and maybe VOTE to reach
>>> concensus?
>>>
>>> My opinion: I think it'd be crazy to leave Jira read/write.  We would
>>> effectively have two issue trackers.  New users who find Jira through
>>> Google, or through links we have in old blog posts, etc., might
>>> accidentally open new Jira issues or comment on old ones and we may not
>>> even notice.  I think that would harm our community.
>>>
>>> I would prefer that we make a nearly atomic switch -- up until time X we
>>> use Jira, then it goes read-only and at time X + t (t being how long the
>>> migration takes, likely a day or two?), GitHub issues opens for business.
>>> This way we clarly have only one issue tracker at (nearly) all times.  This
>>> would make a clean migration, and reduce risk of trapping users.
>>>
>>> Other opinions?
>>>
>>> Thanks,
>>>
>>> Mike
>>> --
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>

Reply via email to