Just an update on the migration procedure. > 2. Send a message to dev@ stating new issues should now be opened in github > 3. Start the migration > I think the difference with this and what was previously described on this thread is there would be no downtime for new issues. I confirmed it's safe to create new issues while the migration is in progress, so there will be no downtime for new issues.
For existing issues, I don't think it'd be practical to suspend our issue system for two or three days, I would migrate comments on existing issues created during migration in Jira by my GitHub account. A bit awkward, but it'd be an acceptable workaround I think. Tomoko 2022年7月19日(火) 23:24 Tomoko Uchida <tomoko.uchida.1...@gmail.com>: > > I think missing a few updates would be preferable to having 10k > messages. Just my opinion though. > I don't have objections. Then let's disable Jira notification on issues@ > before the script is started - maybe, issue watchers will notice that if > there are comments from someone. > Other opinions? > > 2022年7月19日(火) 23:17 Houston Putman <houstonput...@gmail.com>: > >> I think missing a few updates would be preferable to having 10k messages. >> Just my opinion though. >> >> On Tue, Jul 19, 2022 at 10:11 AM Tomoko Uchida < >> tomoko.uchida.1...@gmail.com> wrote: >> >>> > 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. >>>> >>> >>> > Is this going to send 10k emails to the mailing list? I’ll need to >>> update my filters so that these skip my inbox in that case. >>> >>> Yes, I will let you all know the mail template before starting the >>> migration. >>> Or, a Jira project admin could completely disable notifications from >>> Jira - but this could bury real notifications (issues/comments by humans >>> who don't recognize the migration). >>> >>> 2022年7月19日(火) 23:05 Tomoko Uchida <tomoko.uchida.1...@gmail.com>: >>> >>>> > 2. Send a message to dev@ stating new issues should now be opened in >>>> github >>>> > 3. Start the migration >>>> >>>> Maybe we can do a simulation for this. >>>> I plan a rehearsal that migrates whole existing issues into a test repo >>>> next week. Could some people help/test it (randomly open/close issues, add >>>> comments, etc. while the migration script is running)? >>>> >>>> >>>> 2022年7月19日(火) 22:47 Tomoko Uchida <tomoko.uchida.1...@gmail.com>: >>>> >>>>> > 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) >>>>>>>> >>>>>>>
