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