> Yes, it won't be a really atomic switch While it may not be completely atomic, could it be closer? GitHub already supports new issues, developers are just advised against opening there. Could the order of events be:
1. Make Jira read only 2. Send a message to dev@ stating new issues should now be opened in github 3. Start the migration 4. When the migration is complete, send another message notifying devs that pre-existing Jiras are now in GitHub,so they can then be commented on and edited there. I think the difference with this and what was previously described on this thread is there would be no downtime for new issues. On Tue, Jul 19, 2022 at 00:07 Tomoko Uchida <tomoko.uchida.1...@gmail.com> wrote: > OK, thank you everyone for your comments/suggestions. > I will ask infra to make Lucene Jira read-only after the migration is > completed (if there are no explicit objections). For people who are > critically affected by this change, please let me know about your > inconvenience. I'll try to find acceptable solutions. > > > 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. > > Yes, it won't be a really atomic switch - there will be a moratorium in > our issue system (where GitHub issue is not lifted yet, but a Jira snapshot > is already taken). I estimate the whole migration process will take at > least three days; will make a mail thread about the detailed schedule. > > Tomoko > > > 2022年7月19日(火) 2:38 Gus Heck <gus.h...@gmail.com>: > >> I am 100% for preventing creation of new issues in Jira, new issues >> should only be created in one system at any one time. I feel that existing >> issues should be completed in their original system for continuity, and >> anticipate that in any case Jira will mean readable in perpetuity. The >> copying of old issues to github as a convenience for users so they aren't >> forced to look at 2 places also sounds good. Raising the standard for what >> we consider a stale issue and closing out things in Jira faster to get to a >> one system situation sooner also seems good. >> >> Things I think we should strive to avoid: >> 1) An issue in Jira that is unresolved and duplicated (possibly resolved) >> in github... possibly leading to someone wasting time repeating a solution >> or giving up thinking there isn't a solution etc. >> 2) Any issues for which the discussion is split across systems and thus >> it would be easy to miss part of the discussion and/or not have the issue >> come up in searches that are relevant to that issue. >> >> Also, a common pattern for me is to throw an issue ticket number that I >> have noted somewhere (i.e LUCENE-12345) into google and browse to the >> ticket if it comes up directly or to a mail archive result which has a link >> to the Jira. This is faster than searching in jira itself because I can >> always get to google in a single keystroke (new tab). Sadly this is >> unlikely to work with github which does not put a project moniker on the >> issue id. Not sure how many others do this but if it's common I wonder if >> we can auto-insert something of the sort into github tickets so that mail >> archives from the tickets are similarly searchable? Like LUCENE-G12345 for >> github ticket #12345? The two key things that make this useful are the >> searchability of the ID in google and the fact that ticket mails often have >> a link to the ticket which the archive sites will render as a hyperlink. >> >> -Gus >> >> On Mon, Jul 18, 2022 at 11:12 AM David Smiley <dsmi...@apache.org> wrote: >> >>> I suppose someone bent on not using GitHub could also email the patch to >>> the dev list, starting a thread around it. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> >>> On Sun, Jul 17, 2022 at 9:14 AM Michael McCandless < >>> luc...@mikemccandless.com> wrote: >>> >>>> 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 >>>> >>> >> >> -- >> http://www.needhamsoftware.com (work) >> http://www.the111shift.com (play) >> >
