We have two conflicting requests: 1. We don't want to duplicate/diverge issues; an issue's identity is what matters the most. 2. We don't want to keep holding multiple issue systems; having only one system is what matters the most.
They are inevitably in conflict with each other - it looks like many folks put more weight on 1 than 2, then I would go with it. I'd like to set a principle (not a very strict rule) to avoid unnecessary confusion during the migration period. * All new issues should be opened on GitHub. Opening new Jira issues is discouraged unless there is a good reason. * All existing issues should be resolved in Jira. Copying or moving Jira issues to GitHub is discouraged unless there is a good reason. Is there anyone who strongly opposes this? Tomoko 2022年6月16日(木) 5:44 David Smiley <[email protected]>: > > I'm not a fan of the automated copying of any issues into GitHub, which will > create a divergence / duplicity of an issue's identity. It will only be a > relatively temporary annoyance to have two systems to "work" on an issue. > Eventually, JIRA will only be historical; let's say Lucene 11. At that point > if there's an older issue of resumed interest, which would be getting > increasingly rare, someone could manually copy the original description and > title into GitHub plus a historical reference back. Again -- rare by then. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Wed, Jun 15, 2022 at 4:18 PM Tomoko Uchida <[email protected]> > wrote: >> >> It looks like we talked about two or three things at the same time - >> and I'm afraid the discussion will quickly turn into a disordered >> state and I won't be able to track it. >> >> Let me decide one thing: Let's NOT try to move histories to GitHub. >> Closed issues will remain in Jira forever and we can refer to them >> anytime from anywhere. I think I said that before several times. >> >> I would like to focus on the future here - can we make a decision on >> how to handle active (unresolved) issues and issues that will be >> opened in the future. >> >> Thank you, >> Tomoko >> >> 2022年6月16日(木) 4:18 Dawid Weiss <[email protected]>: >> >> > >> > >> >> Totally agree. The history of closed issues answer “when did this change >> >> and why?”. Migrate them all. Computers can do that. It avoids asking >> >> humans to think about where stuff is. >> > >> > >> > We do have different views of that. To me, the history is preserved >> > perfectly well in Jira, it's not being phased out. Moving to github as the >> > issue tracking system is fine but different to me than code transitions >> > (cvs->svn->git). With code, you do have an existing state and history you >> > build from. With issue tickets - not so much. And even if you want to >> > create a ticket in the new system, you can easily link to the previous >> > one. It's the "web" of hyperlinks, right? >> > >> > I'm a bit afraid that moving hundreds of jira issues to github will have >> > the reverse effect - duplicate the same information but with quality >> > degraded, for example automatic links that work in Jira will no longer >> > work or point at the ported github issues ("this is related to LUCENE-xyz >> > or SOLR-abc, blah, blah blah.")? >> > >> > I don't want to stand in the way of progress but we've gone through a >> > similar transition at our company and I never had a problem using both >> > systems at the same time; jira just gradually atrophied into a read-only >> > state once issues in there got stale or resolved. >> > >> > Dawid >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
