I see. If we forbid people from updating Jira, I hope we will keep dealing with .patch files (maybe renamed to XXXX.patch.txt or XXXX-patch.txt) as before. I don't want to interfere with the development style of people who prefer classical/standard patch files over pull requests.
Except for the treatment of .patch files, I don't see any essential difference between Jira and GitHub issues so far. For people who don't use GitHub not because of functionality but because of their policy, I cannot much help. In that case, just blame me - it's a project I started. 2022年7月18日(月) 19:32 Michael McCandless <luc...@mikemccandless.com>: > Indeed, GitHub forbids you from attaching a file with extension .patch! > Sort of annoying :) > > But then one workaround is to rename it to XXXX-patch.txt or so. Of > course, GitHub won't do pretty rendering of the .patch syntax, but then I > don't think Jira does either? It's just an attachment that you must > download and apply to your local git clone. > > GitHub does support mapping a PR to a patch or diff file -- you just > download the full path to the PR, but add .diff or .patch extension. E.g. > https://github.com/apache/lucene-jira-archive/pull/49.patch or > https://github.com/apache/lucene-jira-archive/pull/49.diff. > > The .diff is a straight diff (like "git diff") of all the cumulative > changes/commits in the PR, while the .patch shows a concatenation of the > individual commits. > > Mike McCandless > > http://blog.mikemccandless.com > > > On Mon, Jul 18, 2022 at 12:41 AM Tomoko Uchida < > tomoko.uchida.1...@gmail.com> wrote: > >> 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 >>>>> >>>>
