> 1. Make Jira read only At the very last step, we'll add comments saying "This was moved GitHub <URL>" to each Jira issue. It has to be done after the migration was completed.
> 2. Send a message to dev@ stating new issues should now be opened in github > 3. Start the migration In theory, it would be okay to me. I just wanted to avoid any risks during migration. Let me give time to consider/check if the migration can be safely done while new issues are created (by humans). 2022年7月19日(火) 21:56 Ryan Ernst <r...@iernst.net>: > > 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) >>> >>
