On Tue, Jul 19, 2022 at 8:48 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. > > 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) >>>> >>>
