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