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.weiss@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.1111@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.weiss@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>