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) >>>>>> >>>>>
