Hello, sorry, I'm still trying to catch up here, and getting on an airplane soon, yet I'm unhappy at how this thread is going ;)
> Again - allows for a gradual transition without extra effort for you. I would not ask/expect Tomoko to do this migration. If that really is influencing people's minds here, I volunteer to try to create/iterate the tool that can migrate Jira issues to GitHub, if we can agree that keeping our full history is worthwhile/important. So far it looks like I'm one of maybe only two devs passionately against throwing away the rich history in our issue tracker. Maybe it is because I am too old and have come to value history too much ;) Say two years from now we want to migrate to XYZ issue tracker. Would we choose again to discard past issues (Jira and GitHub issues)? Expect future devs to learn three issue trackers if they want to understand Lucene's rich history? How would such users search across three issues trackers? Or maybe you believe there will never be another issue tracker better than GitHub issues in the whole future of our development ;) We are setting a precedent here, and I think it's bad to say "we discard our history on migrating to the latest issue tracker". We should not rush this decision, and again, if volunteering is the problem, I volunteer to find a way forward. > Is there anyone who strongly opposes this? I'm sorry but I still do. Having two writable issue trackers seems like a recipe for disaster, both short term and long term. Short term: we are relying on good/best intentions of a distributed dev community, instead of a mechanism that would ensure we don't mess up (sorry, a very Amazonian reference: https://www.factoftheday1.com/p/september-7-good-mechanisms-outperform). Are we able to at least block the creation of new issues in Jira going forward, and redirect that to GitHub issues instead? Long term: new future devs won't know how to use Jira. It will be "that old system devs used to use but we don't ever look at". They won't know to go to another search engine to find issues there. They won't subscribe to the lists to see comments from users saying "hey, I hit this issue, I tried the workaround here, it didn't work", etc. This kills me: when new devs search for issues using GitHub, they'll only find the "new" ones, not the Jira ones. They won't know that the big missing issues from Jira every happened. Search determines truth in our issue trackers. Also, say a user adds a comment to a closed Jira issue, saying "this bit me, in version XYZ, but I thought it was fixed?". Only devs who subscribe to updates for the "legacy" Jira will even see that response. Why risk that division? We must optimize for the long-term health of our development community, not for the short-term pain of already expert Jira users. Community over code. > 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. I think this is optimizing for the wrong thing (the pain of we expert Jira users). We should rather optimize for the future developers who replace us and will have zero familiarity with Jira. Also, on moving all Jira issues to GitHub, we can insert at the top of the issue's o.p. the link to the "legacy" Jira issue. Rather, I see the divergence as the opposite: leaving some issues in Jira and new issues in GitHub is painful divergence tax going forwards. To old timers and new developers, Lucene would still have one issue tracker holding all issues, if we carry all issues forward to GitHub. > 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. I don't think this is a rare case. Lucene's rich history is vital, because we are such a long running yet still vibrant open-source community. Say you want to understand why Lucene's file locking works the crazy way it does today? Why does IndexWriter make assertions about locks? Why don't locks typically work on NFS, and you must then use a custom IndexDeletionPolicy? Or why did we move responsibility of retrying deletions from IW to FSDirectory? Or how about why copyBytes allocates new byte arrays instead of reusing? The source control record only contains trivial summaries (often/typically squashed on merge into main, removing perhaps interesting specifics of individual local commits too) of what was a very passionate and tricky debate at the time, captured in our issue tracker. > There would not be so many topics that are controversial except for the current discussion about existing Jira issues, and I think we are close to reaching a conclusion. I think it's premature to say this. I have not yet studied the problem closely, but GitHub issues is indeed quite different from Jira's schema/workflow. We should not rush this -- let's propose the migration and all look at it / make suggestions. Dawid already had a good thing to consider (milestones vs labels). > 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 don't think this is a real conflict. If we migrate every Jira issue to GitHub, each of those, and newly created issues, still have a strong identity in a single issue tracker. We can link back to the "legacy issue tracker" in each Jira -> GitHub migrated issue. > 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 agree the embedded links are tricky. Not sure whether we could do a big rewrite of those links or not ... seems a chicken/egg situation. We could 1) append a forwarding link comment on the Jira issue to its GitHub version, and 2) make Jira read-only so the risk of a user adding a Jira comment on an old issue that then goes into /dev/null, is gone. Sorry for the long passionate rant :) It just drives me crazy that so many of us are choosing to discard our history. Saying "I can always find the issue in Jira" is vacuous -- future Lucene devs won't know how to search in Jira, how to subscribe to Jira updates, etc. We need to optimize for the long-term health of our community, making it easy for new future devs to discover the rich history of why certain decisions were made. If we throw away that history we do the opposite. And once (not if, once) we migrate issue trackers again, we need to set a precedent that we don't then expect future devs to learn N+1 issue trackers for searching history. Mike McCandless http://blog.mikemccandless.com On Fri, Jun 17, 2022 at 2:20 AM Dawid Weiss <dawid.we...@gmail.com> wrote: > > I thinking proposing the way to deal with versions and all "labels" > applying to issues is an important part of the work remaining. I know > you've outlined the way different projects handle this, Tomoko. I can't > really offer my suggestions here - I've dealt with both types (milestones > and labels) and they're equally clumsy at times. :) > > D. > > On Fri, Jun 17, 2022 at 5:20 AM Tomoko Uchida < > tomoko.uchida.1...@gmail.com> wrote: > >> > I see you already have a start at the migration plan, yay! (The >> comment on LUCENE-10557) >> > Could we maybe pull that out into a wiki page so we can more easily >> collaborate on the steps? >> >> There would not be so many topics that are controversial except for >> the current discussion about existing Jira issues, and I think we are >> close to reaching a conclusion. >> I re-summarized the migration steps and tasks to be done in the issue >> description and I will update it when there is progress. (Most of the >> remaining work is an administrative job.) >> >> Tomoko >> >> 2022年6月16日(木) 17:13 Dawid Weiss <dawid.we...@gmail.com>: >> > >> > >> > Hi Tomoko, >> > >> >> >> >> * All new issues should be opened on GitHub. Opening new Jira issues >> >> is discouraged unless there is a good reason. >> > >> > >> > I'm fine with this. New issues from contributors who are not aware of >> the migration can be immediately >> > cloned to github and closed in Jira as well (vide Adrien's previous >> suggestion to make an explicit template in >> > Jira to point people in the right direction). The "discouragement" >> would then probably apply only to those folks who >> > expressed their negative sentiments against github (and don't have an >> account there, for example). >> > >> >> >> >> * All existing issues should be resolved in Jira. Copying or moving >> >> Jira issues to GitHub is discouraged unless there is a good reason. >> > >> > >> > I'm also fine with this. Again - allows for a gradual transition >> without extra effort for you. My experience tells me such >> > transition will be a pretty rapid process anyway. If you take a look at >> how fast it was to switch to pull requests vs. >> > patch-in-jira, it's likely to follow the same kind of pattern. >> > >> > Dawid >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
