Mailing List Archive

On Wed, May 4, 2022 at 10:24 PM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> According to the INFRA issue for the RocketMQ project (Michael McCandless gave the pointer in a comment on the issue; thanks!), a PMC agreement or Vote result is needed for the decision.
> https://issues.apache.org/jira/browse/INFRA-15702
>
> Eventually, we'd need a formal vote, but before that, I'd like to hear general opinions/thoughts (or feelings) on this topic from developers.
>

Thanks for opening the discussion! The original motivation for the
INFRA issue linked above is interesting to me. I didn't know
contributors from China struggled to access Apache JIRA.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

I'd like to see some discussion of pros/cons. Personally I don't have
a lot of experience working with github's issue system, while I have
grown comfortable with JIRA over the years, in spite of its warts.
Here are a few things I like and *don't* like about both systems
(mostly JIRA), but I don't know how github would compare:

1. non-standard text markup is forever confusing me (am I in "markup"
mode or "visual" mode?)
2. search is cumbersome and difficult to use (but Mike M made
https://jirasearch.mikemccandless.com/ which counters this problem)
3. setup is highly configurable, in terms of workflow, statuses,
permissions and so on. Not sure if we need this though?
4. something in our current setup creates a lot of noise on the
mailing list -- every comment seems to appear at least three times,
sometimes formatted nicely, and other times buried in a mountain of
code text. I don't know if this is JIRA, Github, or some unholy union
of the two?
5. I find the Github commenting UI confusing -- what is the difference
between conversation and review comments? How can I reply to a
comment? What if I want to batch up a bunch of replies and send one
email with all of them? Maybe it's just me, but I haven't found
comfort with this yet.
6. Github is owned by a corporation. I assume we'd have enough legal
protections to take our data with us if we need to, but it is possibly
an extra hurdle to be concerned about. Would we need to / want to
maintain a separate copy of the issue history?
7. What would happen with the JIRA history? Would we import it to
Github issues? Leave it archived in JIRA?

On Wed, May 4, 2022 at 10:24 PM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> Hello everyone!
>
> Recently, we relaxed the requirement for creating a Jira issue when opening a pull request (LUCENE-10545).
>
> As the next and bigger (perhaps ambitious) step, I opened a rough proposal for migration to GitHub issue from Jira.
> https://issues.apache.org/jira/browse/LUCENE-10557
>
> According to the INFRA issue for the RocketMQ project (Michael McCandless gave the pointer in a comment on the issue; thanks!), a PMC agreement or Vote result is needed for the decision.
> https://issues.apache.org/jira/browse/INFRA-15702
>
> Eventually, we'd need a formal vote, but before that, I'd like to hear general opinions/thoughts (or feelings) on this topic from developers.
>
> In brief, I think it'd be technically possible and also be good for the project - not only for welcoming new developers who are not familiar with Jira, but also for improving the experiences of long-term contributors by consolidating the conversation platform.
> It'll need some administrative work though, I'm willing to work for it if we reach an agreement.
>
> Please note that:
> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we don't aim to reach a conclusion in this thread.
> * Let's not discuss "how to migrate existing Jira issues" for now. Once we decide the migration will be good for us, then we can try to figure out a reasonable solution for technical/administrative matters.
>
> I may be too optimistic about it; but - a bit of stupidness will be needed to start such a move, and I'm serious about this proposal :)
>
> Thanks and regards,
> Tomoko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

On Thu, May 5, 2022 at 7:49 AM Michael Sokolov <msokolov@gmail.com> wrote:
> 5. I find the Github commenting UI confusing -- what is the difference
> between conversation and review comments? How can I reply to a
> comment? What if I want to batch up a bunch of replies and send one
> email with all of them? Maybe it's just me, but I haven't found
> comfort with this yet.

As far as replies, in github I highlight the part of the thing i want
to reply to, and press 'r' key on my keyboard. it quotes it and
everything. Really convenient to me.

On the other hand, in JIRA, I have to copy/paste myself and add inside
a {quote} bracket, and try to remember to terminate it with another
{quote} (or it gets really confused). I've used JIRA enough to know
that it is unsafe to switch back and forth between "Visual" and "Text"
modes, you might lose your entire comment due to its bugs. So its
impossible to preview what your stuff will look like, you just have to
comment and "hope for the best". This probably causes unnecessary
edits which make even more unholy noise :)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

> The original motivation for the
> INFRA issue linked above is interesting to me. I didn't know
> contributors from China struggled to access Apache JIRA.

Just for a supplement - I did not know that either, but I think it's not
only abouit Jira.
I've seen several times developers in China sometimes struggle also with
connecting to GitHub - may be due to the so-called Great Firewall.
I've also seen the same situation in other services (video chat, etc.) so I
guess it's a general issue that the free internet connection is not
necessarily always available in all countries/regions.

Tomoko


2022?5?5?(?) 20:56 Robert Muir <rcmuir@gmail.com>:

> On Thu, May 5, 2022 at 7:49 AM Michael Sokolov <msokolov@gmail.com> wrote:
> > 5. I find the Github commenting UI confusing -- what is the difference
> > between conversation and review comments? How can I reply to a
> > comment? What if I want to batch up a bunch of replies and send one
> > email with all of them? Maybe it's just me, but I haven't found
> > comfort with this yet.
>
> As far as replies, in github I highlight the part of the thing i want
> to reply to, and press 'r' key on my keyboard. it quotes it and
> everything. Really convenient to me.
>
> On the other hand, in JIRA, I have to copy/paste myself and add inside
> a {quote} bracket, and try to remember to terminate it with another
> {quote} (or it gets really confused). I've used JIRA enough to know
> that it is unsafe to switch back and forth between "Visual" and "Text"
> modes, you might lose your entire comment due to its bugs. So its
> impossible to preview what your stuff will look like, you just have to
> comment and "hope for the best". This probably causes unnecessary
> edits which make even more unholy noise :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

On Thu, May 5, 2022 at 8:14 AM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> Just for a supplement - I did not know that either, but I think it's not only abouit Jira.
> I've seen several times developers in China sometimes struggle also with connecting to GitHub - may be due to the so-called Great Firewall.
> I've also seen the same situation in other services (video chat, etc.) so I guess it's a general issue that the free internet connection is not necessarily always available in all countries/regions.
>

In the past we have had other GFW issues, for example with the build
system not working in China. I remember doing crazy stuff like this:
https://github.com/apache/lucene-solr/commit/f8577e6cb4f228b7280fca627d4ba712a5fde70a
It is difficult for those of us outside of China to help with this
issue, we can't easily test or anything like that. But IMO we should
try.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Ah sorry, if I unintentionally went off the track.

Thanks for your comments - I'll keep this thread for a sufficient period of
time and read all messages.
It's an open discussion and any comments from all developers (PMC members,
committers, contributors) are welcomed and respected.

Tomoko


2022?5?5?(?) 21:26 Robert Muir <rcmuir@gmail.com>:

> On Thu, May 5, 2022 at 8:14 AM Tomoko Uchida
> <tomoko.uchida.1111@gmail.com> wrote:
> >
> > Just for a supplement - I did not know that either, but I think it's not
> only abouit Jira.
> > I've seen several times developers in China sometimes struggle also with
> connecting to GitHub - may be due to the so-called Great Firewall.
> > I've also seen the same situation in other services (video chat, etc.)
> so I guess it's a general issue that the free internet connection is not
> necessarily always available in all countries/regions.
> >
>
> In the past we have had other GFW issues, for example with the build
> system not working in China. I remember doing crazy stuff like this:
>
> https://github.com/apache/lucene-solr/commit/f8577e6cb4f228b7280fca627d4ba712a5fde70a
> It is difficult for those of us outside of China to help with this
> issue, we can't easily test or anything like that. But IMO we should
> try.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Given how JIRA has become a monster of a product with different markup syntax for each version, and bugs everywhere (does not even work on mobile), I'm no longer the JIRA fan I once was.

In Solr we already use github issues for the Solr-Operator sub project https://github.com/apache/solr-operator/issues <https://github.com/apache/solr-operator/issues> and I believe it has worked well. Of course excellent integration with PRs :)
In earlier discussions on this topic, the idea has been shot down with the argument of split bug history and migration challenges. But I think you are wise to delay the HOW discussion for now.
This discussion should also not be about politics. Some may be opposed to Microsoft and GitHub, but as long as the ASF has officially blessed github as an official option, i'ts not a very constructive discussion.
The most important decision point on my part is perception by new / young users. Look at OpenOffice, they have remained on Bugzilla - are you compelled to contribute? :)

Jan

> 5. mai 2022 kl. 04:23 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>
> Hello everyone!
>
> Recently, we relaxed the requirement for creating a Jira issue when opening a pull request (LUCENE-10545 <https://issues.apache.org/jira/browse/LUCENE-10545>).
>
> As the next and bigger (perhaps ambitious) step, I opened a rough proposal for migration to GitHub issue from Jira.
> https://issues.apache.org/jira/browse/LUCENE-10557 <https://issues.apache.org/jira/browse/LUCENE-10557>
>
> According to the INFRA issue for the RocketMQ project (Michael McCandless gave the pointer in a comment on the issue; thanks!), a PMC agreement or Vote result is needed for the decision.
> https://issues.apache.org/jira/browse/INFRA-15702 <https://issues.apache.org/jira/browse/INFRA-15702>
>
> Eventually, we'd need a formal vote, but before that, I'd like to hear general opinions/thoughts (or feelings) on this topic from developers.
>
> In brief, I think it'd be technically possible and also be good for the project - not only for welcoming new developers who are not familiar with Jira, but also for improving the experiences of long-term contributors by consolidating the conversation platform.
> It'll need some administrative work though, I'm willing to work for it if we reach an agreement.
>
> Please note that:
> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we don't aim to reach a conclusion in this thread.
> * Let's not discuss "how to migrate existing Jira issues" for now. Once we decide the migration will be good for us, then we can try to figure out a reasonable solution for technical/administrative matters.
>
> I may be too optimistic about it; but - a bit of stupidness will be needed to start such a move, and I'm serious about this proposal :)
>
> Thanks and regards,
> Tomoko

(Repeating in public what I mentioned in private)


I'm generally opposed to this idea because GitHub has been known to take
political decisions to cut off access to developers just because of their
nationality/region etc. As a community, we should stay politically neutral
and not rely on GitHub to decide on our behalf who to exclude from our
community.

On Thu, 5 May, 2022, 8:45 pm Jan Høydahl, <jan.asf@cominvent.com> wrote:

> Given how JIRA has become a monster of a product with different markup
> syntax for each version, and bugs everywhere (does not even work on
> mobile), I'm no longer the JIRA fan I once was.
>
> In Solr we already use github issues for the Solr-Operator sub project
> https://github.com/apache/solr-operator/issues and I believe it has
> worked well. Of course excellent integration with PRs :)
> In earlier discussions on this topic, the idea has been shot down with the
> argument of split bug history and migration challenges. But I think you are
> wise to delay the HOW discussion for now.
> This discussion should also not be about politics. Some may be opposed to
> Microsoft and GitHub, but as long as the ASF has officially blessed github
> as an official option, i'ts not a very constructive discussion.
> The most important decision point on my part is perception by new / young
> users. Look at OpenOffice, they have remained on Bugzilla - are you
> compelled to contribute? :)
>
> Jan
>
> 5. mai 2022 kl. 04:23 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>
> Hello everyone!
>
> Recently, we relaxed the requirement for creating a Jira issue when
> opening a pull request (LUCENE-10545
> <https://issues.apache.org/jira/browse/LUCENE-10545>).
>
> As the next and bigger (perhaps ambitious) step, I opened a rough proposal
> for migration to GitHub issue from Jira.
> https://issues.apache.org/jira/browse/LUCENE-10557
>
> According to the INFRA issue for the RocketMQ project (Michael McCandless
> gave the pointer in a comment on the issue; thanks!), a PMC agreement or
> Vote result is needed for the decision.
> https://issues.apache.org/jira/browse/INFRA-15702
>
> Eventually, we'd need a formal vote, but before that, I'd like to hear
> general opinions/thoughts (or feelings) on this topic from developers.
>
> In brief, I think it'd be technically possible and also be good for the
> project - not only for welcoming new developers who are not familiar with
> Jira, but also for improving the experiences of long-term contributors by
> consolidating the conversation platform.
> It'll need some administrative work though, I'm willing to work for it if
> we reach an agreement.
>
> Please note that:
> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but
> we don't aim to reach a conclusion in this thread.
> * Let's not discuss "how to migrate existing Jira issues" for now. Once we
> decide the migration will be good for us, then we can try to figure out a
> reasonable solution for technical/administrative matters.
>
> I may be too optimistic about it; but - a bit of stupidness will be needed
> to start such a move, and I'm serious about this proposal :)
>
> Thanks and regards,
> Tomoko
>
>
>

It's really interesting to me to hear how others feel comfortable (or
discomfortable) with the tools!

I myself am not an expert of either JIra or GitHub, and actually have no
feelings on which tool is better.
The only motivation for my proposal was, "consolidate the conversation
platform and reduce the context switch between two platforms".

However, I don't want to narrow the theme of conversation too early, so
please freely express your thoughts.

Hi Ishan,

> I'm generally opposed to this idea because GitHub has been known to take
political decisions to cut off access to developers just because of their
nationality/region etc.

Sorry I haven't heard of such matters for GitHub. Can you please present
the reference?

Tomoko


2022?5?6?(?) 0:41 Ishan Chattopadhyaya <ichattopadhyaya@gmail.com>:

> (Repeating in public what I mentioned in private)
>
>
> I'm generally opposed to this idea because GitHub has been known to take
> political decisions to cut off access to developers just because of their
> nationality/region etc. As a community, we should stay politically neutral
> and not rely on GitHub to decide on our behalf who to exclude from our
> community.
>
> On Thu, 5 May, 2022, 8:45 pm Jan Høydahl, <jan.asf@cominvent.com> wrote:
>
>> Given how JIRA has become a monster of a product with different markup
>> syntax for each version, and bugs everywhere (does not even work on
>> mobile), I'm no longer the JIRA fan I once was.
>>
>> In Solr we already use github issues for the Solr-Operator sub project
>> https://github.com/apache/solr-operator/issues and I believe it has
>> worked well. Of course excellent integration with PRs :)
>> In earlier discussions on this topic, the idea has been shot down with
>> the argument of split bug history and migration challenges. But I think you
>> are wise to delay the HOW discussion for now.
>> This discussion should also not be about politics. Some may be opposed to
>> Microsoft and GitHub, but as long as the ASF has officially blessed github
>> as an official option, i'ts not a very constructive discussion.
>> The most important decision point on my part is perception by new / young
>> users. Look at OpenOffice, they have remained on Bugzilla - are you
>> compelled to contribute? :)
>>
>> Jan
>>
>> 5. mai 2022 kl. 04:23 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>
>> Hello everyone!
>>
>> Recently, we relaxed the requirement for creating a Jira issue when
>> opening a pull request (LUCENE-10545
>> <https://issues.apache.org/jira/browse/LUCENE-10545>).
>>
>> As the next and bigger (perhaps ambitious) step, I opened a rough
>> proposal for migration to GitHub issue from Jira.
>> https://issues.apache.org/jira/browse/LUCENE-10557
>>
>> According to the INFRA issue for the RocketMQ project (Michael McCandless
>> gave the pointer in a comment on the issue; thanks!), a PMC agreement or
>> Vote result is needed for the decision.
>> https://issues.apache.org/jira/browse/INFRA-15702
>>
>> Eventually, we'd need a formal vote, but before that, I'd like to hear
>> general opinions/thoughts (or feelings) on this topic from developers.
>>
>> In brief, I think it'd be technically possible and also be good for the
>> project - not only for welcoming new developers who are not familiar with
>> Jira, but also for improving the experiences of long-term contributors by
>> consolidating the conversation platform.
>> It'll need some administrative work though, I'm willing to work for it if
>> we reach an agreement.
>>
>> Please note that:
>> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but
>> we don't aim to reach a conclusion in this thread.
>> * Let's not discuss "how to migrate existing Jira issues" for now. Once
>> we decide the migration will be good for us, then we can try to figure out
>> a reasonable solution for technical/administrative matters.
>>
>> I may be too optimistic about it; but - a bit of stupidness will be
>> needed to start such a move, and I'm serious about this proposal :)
>>
>> Thanks and regards,
>> Tomoko
>>
>>
>>

> On May 5, 2022, at 08:41, Ishan Chattopadhyaya <ichattopadhyaya@gmail.com> wrote:
>
> ?
> (Repeating in public what I mentioned in private)
>
>
> I'm generally opposed to this idea because GitHub has been known to take political decisions to cut off access to developers just because of their nationality/region etc. As a community, we should stay politically neutral and not rely on GitHub to decide on our behalf who to exclude from our community.

Agreed. My main issue with hosted services like GitHub and others like it is that as they there is no due process, very little recourse, when some AI or other automated process gets you banned. Again, this is an issue for all such services and it's worse the bigger they are. It's also an "all eggs in the same basket" problem.
Thus, I prefer to depend on Apache than on GitHub.
If we want to move off of Jira, I think doing so on a self (Apache)-hosted instance of GitLab would be a lot better and offer the same enticing eye candy and issue/PR integration as GitHub.

Andi..


>
>> On Thu, 5 May, 2022, 8:45 pm Jan Høydahl, <jan.asf@cominvent.com> wrote:
>> Given how JIRA has become a monster of a product with different markup syntax for each version, and bugs everywhere (does not even work on mobile), I'm no longer the JIRA fan I once was.
>>
>> In Solr we already use github issues for the Solr-Operator sub project https://github.com/apache/solr-operator/issues and I believe it has worked well. Of course excellent integration with PRs :)
>> In earlier discussions on this topic, the idea has been shot down with the argument of split bug history and migration challenges. But I think you are wise to delay the HOW discussion for now.
>> This discussion should also not be about politics. Some may be opposed to Microsoft and GitHub, but as long as the ASF has officially blessed github as an official option, i'ts not a very constructive discussion.
>> The most important decision point on my part is perception by new / young users. Look at OpenOffice, they have remained on Bugzilla - are you compelled to contribute? :)
>>
>> Jan
>>
>>> 5. mai 2022 kl. 04:23 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>>
>>> Hello everyone!
>>>
>>> Recently, we relaxed the requirement for creating a Jira issue when opening a pull request (LUCENE-10545).
>>>
>>> As the next and bigger (perhaps ambitious) step, I opened a rough proposal for migration to GitHub issue from Jira.
>>> https://issues.apache.org/jira/browse/LUCENE-10557
>>>
>>> According to the INFRA issue for the RocketMQ project (Michael McCandless gave the pointer in a comment on the issue; thanks!), a PMC agreement or Vote result is needed for the decision.
>>> https://issues.apache.org/jira/browse/INFRA-15702
>>>
>>> Eventually, we'd need a formal vote, but before that, I'd like to hear general opinions/thoughts (or feelings) on this topic from developers.
>>>
>>> In brief, I think it'd be technically possible and also be good for the project - not only for welcoming new developers who are not familiar with Jira, but also for improving the experiences of long-term contributors by consolidating the conversation platform.
>>> It'll need some administrative work though, I'm willing to work for it if we reach an agreement.
>>>
>>> Please note that:
>>> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we don't aim to reach a conclusion in this thread.
>>> * Let's not discuss "how to migrate existing Jira issues" for now. Once we decide the migration will be good for us, then we can try to figure out a reasonable solution for technical/administrative matters.
>>>
>>> I may be too optimistic about it; but - a bit of stupidness will be needed to start such a move, and I'm serious about this proposal :)
>>>
>>> Thanks and regards,
>>> Tomoko
>>

> On May 5, 2022, at 08:49, Tomoko Uchida <tomoko.uchida.1111@gmail.com> wrote:
>
> ?
> It's really interesting to me to hear how others feel comfortable (or discomfortable) with the tools!
>
> I myself am not an expert of either JIra or GitHub, and actually have no feelings on which tool is better.
> The only motivation for my proposal was, "consolidate the conversation platform and reduce the context switch between two platforms".
>
> However, I don't want to narrow the theme of conversation too early, so please freely express your thoughts.

My main gripe with Jira is that I can't respond to Jira comments via email. I have to always use their interface.

Andi..

>
> Hi Ishan,
>
> > I'm generally opposed to this idea because GitHub has been known to take political decisions to cut off access to developers just because of their nationality/region etc.
>
> Sorry I haven't heard of such matters for GitHub. Can you please present the reference?
>
> Tomoko
>
>
> 2022?5?6?(?) 0:41 Ishan Chattopadhyaya <ichattopadhyaya@gmail.com>:
>> (Repeating in public what I mentioned in private)
>>
>>
>> I'm generally opposed to this idea because GitHub has been known to take political decisions to cut off access to developers just because of their nationality/region etc. As a community, we should stay politically neutral and not rely on GitHub to decide on our behalf who to exclude from our community.
>>
>>> On Thu, 5 May, 2022, 8:45 pm Jan Høydahl, <jan.asf@cominvent.com> wrote:
>>> Given how JIRA has become a monster of a product with different markup syntax for each version, and bugs everywhere (does not even work on mobile), I'm no longer the JIRA fan I once was.
>>>
>>> In Solr we already use github issues for the Solr-Operator sub project https://github.com/apache/solr-operator/issues and I believe it has worked well. Of course excellent integration with PRs :)
>>> In earlier discussions on this topic, the idea has been shot down with the argument of split bug history and migration challenges. But I think you are wise to delay the HOW discussion for now.
>>> This discussion should also not be about politics. Some may be opposed to Microsoft and GitHub, but as long as the ASF has officially blessed github as an official option, i'ts not a very constructive discussion.
>>> The most important decision point on my part is perception by new / young users. Look at OpenOffice, they have remained on Bugzilla - are you compelled to contribute? :)
>>>
>>> Jan
>>>
>>>> 5. mai 2022 kl. 04:23 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>>>
>>>> Hello everyone!
>>>>
>>>> Recently, we relaxed the requirement for creating a Jira issue when opening a pull request (LUCENE-10545).
>>>>
>>>> As the next and bigger (perhaps ambitious) step, I opened a rough proposal for migration to GitHub issue from Jira.
>>>> https://issues.apache.org/jira/browse/LUCENE-10557
>>>>
>>>> According to the INFRA issue for the RocketMQ project (Michael McCandless gave the pointer in a comment on the issue; thanks!), a PMC agreement or Vote result is needed for the decision.
>>>> https://issues.apache.org/jira/browse/INFRA-15702
>>>>
>>>> Eventually, we'd need a formal vote, but before that, I'd like to hear general opinions/thoughts (or feelings) on this topic from developers.
>>>>
>>>> In brief, I think it'd be technically possible and also be good for the project - not only for welcoming new developers who are not familiar with Jira, but also for improving the experiences of long-term contributors by consolidating the conversation platform.
>>>> It'll need some administrative work though, I'm willing to work for it if we reach an agreement.
>>>>
>>>> Please note that:
>>>> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we don't aim to reach a conclusion in this thread.
>>>> * Let's not discuss "how to migrate existing Jira issues" for now. Once we decide the migration will be good for us, then we can try to figure out a reasonable solution for technical/administrative matters.
>>>>
>>>> I may be too optimistic about it; but - a bit of stupidness will be needed to start such a move, and I'm serious about this proposal :)
>>>>
>>>> Thanks and regards,
>>>> Tomoko
>>>

OK, I think it's a healthy discussion everyone can make an assertion
(agreement or disagreement, or whatever else).

I'd ask all just one thing - if you criticize or strongly oppose any tools,
please present references that support your opinion.

Thank you,
Tomoko


2022?5?6?(?) 1:17 Andi Vajda <osaf@ovaltofu.org>:

>
> On May 5, 2022, at 08:41, Ishan Chattopadhyaya <ichattopadhyaya@gmail.com>
> wrote:
>
> ?
> (Repeating in public what I mentioned in private)
>
>
> I'm generally opposed to this idea because GitHub has been known to take
> political decisions to cut off access to developers just because of their
> nationality/region etc. As a community, we should stay politically neutral
> and not rely on GitHub to decide on our behalf who to exclude from our
> community.
>
>
> Agreed. My main issue with hosted services like GitHub and others like it
> is that as they there is no due process, very little recourse, when some AI
> or other automated process gets you banned. Again, this is an issue for all
> such services and it's worse the bigger they are. It's also an "all eggs in
> the same basket" problem.
> Thus, I prefer to depend on Apache than on GitHub.
> If we want to move off of Jira, I think doing so on a self (Apache)-hosted
> instance of GitLab would be a lot better and offer the same enticing eye
> candy and issue/PR integration as GitHub.
>
> Andi..
>
>
>
> On Thu, 5 May, 2022, 8:45 pm Jan Høydahl, <jan.asf@cominvent.com> wrote:
>
>> Given how JIRA has become a monster of a product with different markup
>> syntax for each version, and bugs everywhere (does not even work on
>> mobile), I'm no longer the JIRA fan I once was.
>>
>> In Solr we already use github issues for the Solr-Operator sub project
>> https://github.com/apache/solr-operator/issues and I believe it has
>> worked well. Of course excellent integration with PRs :)
>> In earlier discussions on this topic, the idea has been shot down with
>> the argument of split bug history and migration challenges. But I think you
>> are wise to delay the HOW discussion for now.
>> This discussion should also not be about politics. Some may be opposed to
>> Microsoft and GitHub, but as long as the ASF has officially blessed github
>> as an official option, i'ts not a very constructive discussion.
>> The most important decision point on my part is perception by new / young
>> users. Look at OpenOffice, they have remained on Bugzilla - are you
>> compelled to contribute? :)
>>
>> Jan
>>
>> 5. mai 2022 kl. 04:23 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>
>> Hello everyone!
>>
>> Recently, we relaxed the requirement for creating a Jira issue when
>> opening a pull request (LUCENE-10545
>> <https://issues.apache.org/jira/browse/LUCENE-10545>).
>>
>> As the next and bigger (perhaps ambitious) step, I opened a rough
>> proposal for migration to GitHub issue from Jira.
>> https://issues.apache.org/jira/browse/LUCENE-10557
>>
>> According to the INFRA issue for the RocketMQ project (Michael McCandless
>> gave the pointer in a comment on the issue; thanks!), a PMC agreement or
>> Vote result is needed for the decision.
>> https://issues.apache.org/jira/browse/INFRA-15702
>>
>> Eventually, we'd need a formal vote, but before that, I'd like to hear
>> general opinions/thoughts (or feelings) on this topic from developers.
>>
>> In brief, I think it'd be technically possible and also be good for the
>> project - not only for welcoming new developers who are not familiar with
>> Jira, but also for improving the experiences of long-term contributors by
>> consolidating the conversation platform.
>> It'll need some administrative work though, I'm willing to work for it if
>> we reach an agreement.
>>
>> Please note that:
>> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but
>> we don't aim to reach a conclusion in this thread.
>> * Let's not discuss "how to migrate existing Jira issues" for now. Once
>> we decide the migration will be good for us, then we can try to figure out
>> a reasonable solution for technical/administrative matters.
>>
>> I may be too optimistic about it; but - a bit of stupidness will be
>> needed to start such a move, and I'm serious about this proposal :)
>>
>> Thanks and regards,
>> Tomoko
>>
>>
>>

Is anyone familiar with using GitHub (or maybe GitLab I suppose) for
tracking metadata about the issue -- something JIRA excels at? For example
the version of our project that a given PR is released in -- aka the JIRA
"Fix Version"?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, May 4, 2022 at 10:24 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> Hello everyone!
>
> Recently, we relaxed the requirement for creating a Jira issue when
> opening a pull request (LUCENE-10545
> <https://issues.apache.org/jira/browse/LUCENE-10545>).
>
> As the next and bigger (perhaps ambitious) step, I opened a rough proposal
> for migration to GitHub issue from Jira.
> https://issues.apache.org/jira/browse/LUCENE-10557
>
> According to the INFRA issue for the RocketMQ project (Michael McCandless
> gave the pointer in a comment on the issue; thanks!), a PMC agreement or
> Vote result is needed for the decision.
> https://issues.apache.org/jira/browse/INFRA-15702
>
> Eventually, we'd need a formal vote, but before that, I'd like to hear
> general opinions/thoughts (or feelings) on this topic from developers.
>
> In brief, I think it'd be technically possible and also be good for the
> project - not only for welcoming new developers who are not familiar with
> Jira, but also for improving the experiences of long-term contributors by
> consolidating the conversation platform.
> It'll need some administrative work though, I'm willing to work for it if
> we reach an agreement.
>
> Please note that:
> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but
> we don't aim to reach a conclusion in this thread.
> * Let's not discuss "how to migrate existing Jira issues" for now. Once we
> decide the migration will be good for us, then we can try to figure out a
> reasonable solution for technical/administrative matters.
>
> I may be too optimistic about it; but - a bit of stupidness will be needed
> to start such a move, and I'm serious about this proposal :)
>
> Thanks and regards,
> Tomoko
>

ASF has officially blessed use of github issues as alternative to Jira. They are not going to setup a private GitLab or tool X. While GitLab is nice, I don't think the main intention with the proposal was to inroduce yet another platform where contributors need to register an account and learn the UI :)


GitHub issues versions are tracked in "Milestones" - https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones <https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones>

See example from solr-operator. These issues or PRs were released in v0.5.1: https://github.com/apache/solr-operator/milestone/8?closed=1 <https://github.com/apache/solr-operator/milestone/8?closed=1>
Labels are also very flexibl.

Jan

> 5. mai 2022 kl. 22:18 skrev David Smiley <dsmiley@apache.org>:
>
> Is anyone familiar with using GitHub (or maybe GitLab I suppose) for tracking metadata about the issue -- something JIRA excels at? For example the version of our project that a given PR is released in -- aka the JIRA "Fix Version"?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>
> On Wed, May 4, 2022 at 10:24 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com <mailto:tomoko.uchida.1111@gmail.com>> wrote:
> Hello everyone!
>
> Recently, we relaxed the requirement for creating a Jira issue when opening a pull request (LUCENE-10545 <https://issues.apache.org/jira/browse/LUCENE-10545>).
>
> As the next and bigger (perhaps ambitious) step, I opened a rough proposal for migration to GitHub issue from Jira.
> https://issues.apache.org/jira/browse/LUCENE-10557 <https://issues.apache.org/jira/browse/LUCENE-10557>
>
> According to the INFRA issue for the RocketMQ project (Michael McCandless gave the pointer in a comment on the issue; thanks!), a PMC agreement or Vote result is needed for the decision.
> https://issues.apache.org/jira/browse/INFRA-15702 <https://issues.apache.org/jira/browse/INFRA-15702>
>
> Eventually, we'd need a formal vote, but before that, I'd like to hear general opinions/thoughts (or feelings) on this topic from developers.
>
> In brief, I think it'd be technically possible and also be good for the project - not only for welcoming new developers who are not familiar with Jira, but also for improving the experiences of long-term contributors by consolidating the conversation platform.
> It'll need some administrative work though, I'm willing to work for it if we reach an agreement.
>
> Please note that:
> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we don't aim to reach a conclusion in this thread.
> * Let's not discuss "how to migrate existing Jira issues" for now. Once we decide the migration will be good for us, then we can try to figure out a reasonable solution for technical/administrative matters.
>
> I may be too optimistic about it; but - a bit of stupidness will be needed to start such a move, and I'm serious about this proposal :)
>
> Thanks and regards,
> Tomoko

On Thu, 5 May 2022, Jan H?ydahl wrote:

> ASF has officially blessed use of github issues as alternative to Jira.
> They are not going to setup a private GitLab or tool X. While GitLab is
> nice, I don't think the main intention with the proposal was to inroduce
> yet another platform where contributors need to register an account and
> learn the UI :)

That's precisely the crux of the disagreement: I want to be able to register
an account at Apache and *not* GitHub and still be able to contribute. So
yes, registering accounts in various places makes one's participation in
them more resilient to auto-banning-without-due-process-nor-recourse.

As for learning the new UI, GitLab and GitHub are very alike.

Is the original Jira -> GitHub move just a change of defaults or are we,
once moved to GitHub, not letting people use Jira at all anymore ?

Andi..

>
>
> GitHub issues versions are tracked in "Milestones" - https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones <https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones>
>
> See example from solr-operator. These issues or PRs were released in v0.5.1: https://github.com/apache/solr-operator/milestone/8?closed=1 <https://github.com/apache/solr-operator/milestone/8?closed=1>
> Labels are also very flexibl.
>
> Jan
>
>> 5. mai 2022 kl. 22:18 skrev David Smiley <dsmiley@apache.org>:
>>
>> Is anyone familiar with using GitHub (or maybe GitLab I suppose) for tracking metadata about the issue -- something JIRA excels at? For example the version of our project that a given PR is released in -- aka the JIRA "Fix Version"?
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>>
>> On Wed, May 4, 2022 at 10:24 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com <mailto:tomoko.uchida.1111@gmail.com>> wrote:
>> Hello everyone!
>>
>> Recently, we relaxed the requirement for creating a Jira issue when opening a pull request (LUCENE-10545 <https://issues.apache.org/jira/browse/LUCENE-10545>).
>>
>> As the next and bigger (perhaps ambitious) step, I opened a rough proposal for migration to GitHub issue from Jira.
>> https://issues.apache.org/jira/browse/LUCENE-10557 <https://issues.apache.org/jira/browse/LUCENE-10557>
>>
>> According to the INFRA issue for the RocketMQ project (Michael McCandless gave the pointer in a comment on the issue; thanks!), a PMC agreement or Vote result is needed for the decision.
>> https://issues.apache.org/jira/browse/INFRA-15702 <https://issues.apache.org/jira/browse/INFRA-15702>
>>
>> Eventually, we'd need a formal vote, but before that, I'd like to hear general opinions/thoughts (or feelings) on this topic from developers.
>>
>> In brief, I think it'd be technically possible and also be good for the project - not only for welcoming new developers who are not familiar with Jira, but also for improving the experiences of long-term contributors by consolidating the conversation platform.
>> It'll need some administrative work though, I'm willing to work for it if we reach an agreement.
>>
>> Please note that:
>> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we don't aim to reach a conclusion in this thread.
>> * Let's not discuss "how to migrate existing Jira issues" for now. Once we decide the migration will be good for us, then we can try to figure out a reasonable solution for technical/administrative matters.
>>
>> I may be too optimistic about it; but - a bit of stupidness will be needed to start such a move, and I'm serious about this proposal :)
>>
>> Thanks and regards,
>> Tomoko
>
>

> Is the original Jira -> GitHub move just a change of defaults or are we,
> once moved to GitHub, not letting people use Jira at all anymore ?

Nothing has been decided - it's all open for debate.

I just want to re-state the idea (at least as I heard it) behind this
proposed move is to make contributing more accessible.

As for github banning people, just google "github banning" and you
will see that people have been banned for a variety of reasons.

I don't know if the risk of that outweighs the inconvenience of JIRA
for the new developer.

Please note that the primary avenue for contributions today *is
already github*. So far we have not had any issues with people being
banned, and if that were to happen, we still accept patch files in
JIRA. We have had these two mechanisms in place for quite a while now
and both are in active use.

But this proposal is about issue tracking anyway: I just point out
that we already rely on github in spite of its shortcomings.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Thanks for starting this thread, Tomoko! Being fairly new to the community,
I can recall some early teething issues and offer a newcomer's perspective.

Jira took a while to get familiar with. I had used GitHub issues before,
for Elasticsearch and Opensearch. Having used Jira now, makes me like
GitHub a whole lot more. I like the standard markdown support, and overall
experience. GitHub labels (and their UX placement), are great for
discovering new issues and narrowing down your search. (I suppose Jira can
do that too, but haven't gotten there yet).

I remember frequently finding myself getting signed out and forgetting my
Jira password in my initial days. Not having to create another account for
Jira, or sign into two different systems is a big plus.


Vigya


On Thu, May 5, 2022 at 2:51 PM Michael Sokolov <msokolov@gmail.com> wrote:

> > Is the original Jira -> GitHub move just a change of defaults or are we,
> > once moved to GitHub, not letting people use Jira at all anymore ?
>
> Nothing has been decided - it's all open for debate.
>
> I just want to re-state the idea (at least as I heard it) behind this
> proposed move is to make contributing more accessible.
>
> As for github banning people, just google "github banning" and you
> will see that people have been banned for a variety of reasons.
>
> I don't know if the risk of that outweighs the inconvenience of JIRA
> for the new developer.
>
> Please note that the primary avenue for contributions today *is
> already github*. So far we have not had any issues with people being
> banned, and if that were to happen, we still accept patch files in
> JIRA. We have had these two mechanisms in place for quite a while now
> and both are in active use.
>
> But this proposal is about issue tracking anyway: I just point out
> that we already rely on github in spite of its shortcomings.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

--
- Vigya

I agree with that.

What annoys me is that I have to open a fake issue in Jira. I think we should allow people to open GitHub PR or issues. It gets reported also to mailing list. If a Lucene committer does not want to use GitHub, heshe can just download the PR as patch file and apply. Same for issues: all is mirrored to mailing list.

If our users want to open issues they should do what they prefer.

Uwe

Am 5. Mai 2022 21:50:58 UTC schrieb Michael Sokolov <msokolov@gmail.com>:
>> Is the original Jira -> GitHub move just a change of defaults or are we,
>> once moved to GitHub, not letting people use Jira at all anymore ?
>
>Nothing has been decided - it's all open for debate.
>
>I just want to re-state the idea (at least as I heard it) behind this
>proposed move is to make contributing more accessible.
>
>As for github banning people, just google "github banning" and you
>will see that people have been banned for a variety of reasons.
>
>I don't know if the risk of that outweighs the inconvenience of JIRA
>for the new developer.
>
>Please note that the primary avenue for contributions today *is
>already github*. So far we have not had any issues with people being
>banned, and if that were to happen, we still accept patch files in
>JIRA. We have had these two mechanisms in place for quite a while now
>and both are in active use.
>
>But this proposal is about issue tracking anyway: I just point out
>that we already rely on github in spite of its shortcomings.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>For additional commands, e-mail: dev-help@lucene.apache.org
>

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

I'm not going to thoroughly discuss the migration path from Jira to GitHub
here, but generally, the rough image in my mind is the same as Jan
described - "Milestone" for version tracking, and "labels" for other
purposes (issue types, component types, etc.).

As for the proposal of in-house GitLab, it could be an option (if UI/UX is
the only problem) but I don't think it's feasible.
We need high availability platform and we don't have machine/human
resources to operate such mission-critical in-house service on our own.
And, even if it's possible, we still have to switch between two platforms -
it doesn't solve my problem.

> That's precisely the crux of the disagreement: I want to be able to
register
> an account at Apache and *not* GitHub and still be able to contribute.

> Is the original Jira -> GitHub move just a change of defaults or are we,
> once moved to GitHub, not letting people use Jira at all anymore ?

Interesting point - is there anyone else who doesn't have or use GitHub
account and *won't sign up or sign in for it* ?

Tomoko


2022?5?6?(?) 7:04 Uwe Schindler <uwe@thetaphi.de>:

> I agree with that.
>
> What annoys me is that I have to open a fake issue in Jira. I think we
> should allow people to open GitHub PR or issues. It gets reported also to
> mailing list. If a Lucene committer does not want to use GitHub, heshe can
> just download the PR as patch file and apply. Same for issues: all is
> mirrored to mailing list.
>
> If our users want to open issues they should do what they prefer.
>
> Uwe
>
> Am 5. Mai 2022 21:50:58 UTC schrieb Michael Sokolov <msokolov@gmail.com>:
>>
>> Is the original Jira -> GitHub move just a change of defaults or are we,
>>> once moved to GitHub, not letting people use Jira at all anymore ?
>>>
>>
>> Nothing has been decided - it's all open for debate.
>>
>> I just want to re-state the idea (at least as I heard it) behind this
>> proposed move is to make contributing more accessible.
>>
>> As for github banning people, just google "github banning" and you
>> will see that people have been banned for a variety of reasons.
>>
>> I don't know if the risk of that outweighs the inconvenience of JIRA
>> for the new developer.
>>
>> Please note that the primary avenue for contributions today *is
>> already github*. So far we have not had any issues with people being
>> banned, and if that were to happen, we still accept patch files in
>> JIRA. We have had these two mechanisms in place for quite a while now
>> and both are in active use.
>>
>> But this proposal is about issue tracking anyway: I just point out
>> that we already rely on github in spite of its shortcomings.
>> ------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>

Hi Tomoko,

Thanks for raising this discussion!

As a new member of the Lucene community, I'm also confused by the input
components when creating a Jira issue. I struggled with previewing my text
and had to edit it after creating a Jira issue or a comment, and I just
found that each re-edit would send an email notification to the list ????

I only used the GitHub issue system on a small team scale and I am getting
familiar with Jira now. It would be very helpful if we can create a clear
instruction/guide for new developers on how to create an issue no matter
which system we choose in the future.

Best,
Yuting

On Thu, May 5, 2022 at 6:00 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> I'm not going to thoroughly discuss the migration path from Jira to GitHub
> here, but generally, the rough image in my mind is the same as Jan
> described - "Milestone" for version tracking, and "labels" for other
> purposes (issue types, component types, etc.).
>
> As for the proposal of in-house GitLab, it could be an option (if UI/UX is
> the only problem) but I don't think it's feasible.
> We need high availability platform and we don't have machine/human
> resources to operate such mission-critical in-house service on our own.
> And, even if it's possible, we still have to switch between two platforms -
> it doesn't solve my problem.
>
> > That's precisely the crux of the disagreement: I want to be able to
> register
> > an account at Apache and *not* GitHub and still be able to contribute.
>
> > Is the original Jira -> GitHub move just a change of defaults or are we,
> > once moved to GitHub, not letting people use Jira at all anymore ?
>
> Interesting point - is there anyone else who doesn't have or use GitHub
> account and *won't sign up or sign in for it* ?
>
> Tomoko
>
>
> 2022?5?6?(?) 7:04 Uwe Schindler <uwe@thetaphi.de>:
>
>> I agree with that.
>>
>> What annoys me is that I have to open a fake issue in Jira. I think we
>> should allow people to open GitHub PR or issues. It gets reported also to
>> mailing list. If a Lucene committer does not want to use GitHub, heshe can
>> just download the PR as patch file and apply. Same for issues: all is
>> mirrored to mailing list.
>>
>> If our users want to open issues they should do what they prefer.
>>
>> Uwe
>>
>> Am 5. Mai 2022 21:50:58 UTC schrieb Michael Sokolov <msokolov@gmail.com>:
>>>
>>> Is the original Jira -> GitHub move just a change of defaults or are we,
>>>> once moved to GitHub, not letting people use Jira at all anymore ?
>>>>
>>>
>>> Nothing has been decided - it's all open for debate.
>>>
>>> I just want to re-state the idea (at least as I heard it) behind this
>>> proposed move is to make contributing more accessible.
>>>
>>> As for github banning people, just google "github banning" and you
>>> will see that people have been banned for a variety of reasons.
>>>
>>> I don't know if the risk of that outweighs the inconvenience of JIRA
>>> for the new developer.
>>>
>>> Please note that the primary avenue for contributions today *is
>>> already github*. So far we have not had any issues with people being
>>> banned, and if that were to happen, we still accept patch files in
>>> JIRA. We have had these two mechanisms in place for quite a while now
>>> and both are in active use.
>>>
>>> But this proposal is about issue tracking anyway: I just point out
>>> that we already rely on github in spite of its shortcomings.
>>> ------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>

Hi Yuting,
thanks for your feedback.
For your information, we have a general issue to improve our contribution
workflow: LUCENE-10543 <https://issues.apache.org/jira/browse/LUCENE-10543>,
and this is actually a sub-task of it.
You and anyone can contribute to it by leaving comments, creating
documentation or instruction for developers, or whatever else (if you'd
like!).

I'll try to keep this thread a safe place for everyone though, I'd
especially appreciate feedback from newcomers like Vigya and Yuting, since
I understand and remember it is more difficult (and sometimes fearful) to
join discussions for new developers than long-time contributors.

Tomoko


2022?5?6?(?) 11:16 Yuti G <gan.yuti@gmail.com>:

> Hi Tomoko,
>
> Thanks for raising this discussion!
>
> As a new member of the Lucene community, I'm also confused by the input
> components when creating a Jira issue. I struggled with previewing my text
> and had to edit it after creating a Jira issue or a comment, and I just
> found that each re-edit would send an email notification to the list ????
>
> I only used the GitHub issue system on a small team scale and I am getting
> familiar with Jira now. It would be very helpful if we can create a clear
> instruction/guide for new developers on how to create an issue no matter
> which system we choose in the future.
>
> Best,
> Yuting
>
> On Thu, May 5, 2022 at 6:00 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
> wrote:
>
>> I'm not going to thoroughly discuss the migration path from Jira to
>> GitHub here, but generally, the rough image in my mind is the same as Jan
>> described - "Milestone" for version tracking, and "labels" for other
>> purposes (issue types, component types, etc.).
>>
>> As for the proposal of in-house GitLab, it could be an option (if UI/UX
>> is the only problem) but I don't think it's feasible.
>> We need high availability platform and we don't have machine/human
>> resources to operate such mission-critical in-house service on our own.
>> And, even if it's possible, we still have to switch between two platforms -
>> it doesn't solve my problem.
>>
>> > That's precisely the crux of the disagreement: I want to be able to
>> register
>> > an account at Apache and *not* GitHub and still be able to contribute.
>>
>> > Is the original Jira -> GitHub move just a change of defaults or are
>> we,
>> > once moved to GitHub, not letting people use Jira at all anymore ?
>>
>> Interesting point - is there anyone else who doesn't have or use GitHub
>> account and *won't sign up or sign in for it* ?
>>
>> Tomoko
>>
>>
>> 2022?5?6?(?) 7:04 Uwe Schindler <uwe@thetaphi.de>:
>>
>>> I agree with that.
>>>
>>> What annoys me is that I have to open a fake issue in Jira. I think we
>>> should allow people to open GitHub PR or issues. It gets reported also to
>>> mailing list. If a Lucene committer does not want to use GitHub, heshe can
>>> just download the PR as patch file and apply. Same for issues: all is
>>> mirrored to mailing list.
>>>
>>> If our users want to open issues they should do what they prefer.
>>>
>>> Uwe
>>>
>>> Am 5. Mai 2022 21:50:58 UTC schrieb Michael Sokolov <msokolov@gmail.com
>>> >:
>>>>
>>>> Is the original Jira -> GitHub move just a change of defaults or are we,
>>>>> once moved to GitHub, not letting people use Jira at all anymore ?
>>>>>
>>>>
>>>> Nothing has been decided - it's all open for debate.
>>>>
>>>> I just want to re-state the idea (at least as I heard it) behind this
>>>> proposed move is to make contributing more accessible.
>>>>
>>>> As for github banning people, just google "github banning" and you
>>>> will see that people have been banned for a variety of reasons.
>>>>
>>>> I don't know if the risk of that outweighs the inconvenience of JIRA
>>>> for the new developer.
>>>>
>>>> Please note that the primary avenue for contributions today *is
>>>> already github*. So far we have not had any issues with people being
>>>> banned, and if that were to happen, we still accept patch files in
>>>> JIRA. We have had these two mechanisms in place for quite a while now
>>>> and both are in active use.
>>>>
>>>> But this proposal is about issue tracking anyway: I just point out
>>>> that we already rely on github in spite of its shortcomings.
>>>> ------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de
>>>
>>

For code changes, patch files in Jira used to be the only option. Over the years, this is almost completely replaced by PRs, but we still leave the door open for patch in JIRA.
We could apply the same principle here: Don't shut down JIRA, but change documentation so that GitHub issues is documented first. A contributor who for some reason is prohibited to use a GitHub account can then use the JIRA+patch workflow and CHANGES.txt will record the JIRA issue, in-between all the github-issues. BWT: All issues, both in JIRA and GitHub are readable to the public without a user account.

Jan

> 6. mai 2022 kl. 05:15 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>
> Hi Yuting,
> thanks for your feedback.
> For your information, we have a general issue to improve our contribution workflow: LUCENE-10543 <https://issues.apache.org/jira/browse/LUCENE-10543>, and this is actually a sub-task of it.
> You and anyone can contribute to it by leaving comments, creating documentation or instruction for developers, or whatever else (if you'd like!).
>
> I'll try to keep this thread a safe place for everyone though, I'd especially appreciate feedback from newcomers like Vigya and Yuting, since I understand and remember it is more difficult (and sometimes fearful) to join discussions for new developers than long-time contributors.
>
> Tomoko
>
>
> 2022?5?6?(?) 11:16 Yuti G <gan.yuti@gmail.com <mailto:gan.yuti@gmail.com>>:
> Hi Tomoko,
>
> Thanks for raising this discussion!
>
> As a new member of the Lucene community, I'm also confused by the input components when creating a Jira issue. I struggled with previewing my text and had to edit it after creating a Jira issue or a comment, and I just found that each re-edit would send an email notification to the list ????
>
> I only used the GitHub issue system on a small team scale and I am getting familiar with Jira now. It would be very helpful if we can create a clear instruction/guide for new developers on how to create an issue no matter which system we choose in the future.
>
> Best,
> Yuting
>
> On Thu, May 5, 2022 at 6:00 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com <mailto:tomoko.uchida.1111@gmail.com>> wrote:
> I'm not going to thoroughly discuss the migration path from Jira to GitHub here, but generally, the rough image in my mind is the same as Jan described - "Milestone" for version tracking, and "labels" for other purposes (issue types, component types, etc.).
>
> As for the proposal of in-house GitLab, it could be an option (if UI/UX is the only problem) but I don't think it's feasible.
> We need high availability platform and we don't have machine/human resources to operate such mission-critical in-house service on our own. And, even if it's possible, we still have to switch between two platforms - it doesn't solve my problem.
>
> > That's precisely the crux of the disagreement: I want to be able to register
> > an account at Apache and *not* GitHub and still be able to contribute.
>
> > Is the original Jira -> GitHub move just a change of defaults or are we,
> > once moved to GitHub, not letting people use Jira at all anymore ?
>
> Interesting point - is there anyone else who doesn't have or use GitHub account and *won't sign up or sign in for it* ?
>
> Tomoko
>
>
> 2022?5?6?(?) 7:04 Uwe Schindler <uwe@thetaphi.de <mailto:uwe@thetaphi.de>>:
> I agree with that.
>
> What annoys me is that I have to open a fake issue in Jira. I think we should allow people to open GitHub PR or issues. It gets reported also to mailing list. If a Lucene committer does not want to use GitHub, heshe can just download the PR as patch file and apply. Same for issues: all is mirrored to mailing list.
>
> If our users want to open issues they should do what they prefer.
>
> Uwe
>
> Am 5. Mai 2022 21:50:58 UTC schrieb Michael Sokolov <msokolov@gmail.com <mailto:msokolov@gmail.com>>:
> Is the original Jira -> GitHub move just a change of defaults or are we,
> once moved to GitHub, not letting people use Jira at all anymore ?
>
> Nothing has been decided - it's all open for debate.
>
> I just want to re-state the idea (at least as I heard it) behind this
> proposed move is to make contributing more accessible.
>
> As for github banning people, just google "github banning" and you
> will see that people have been banned for a variety of reasons.
>
> I don't know if the risk of that outweighs the inconvenience of JIRA
> for the new developer.
>
> Please note that the primary avenue for contributions today *is
> already github*. So far we have not had any issues with people being
> banned, and if that were to happen, we still accept patch files in
> JIRA. We have had these two mechanisms in place for quite a while now
> and both are in active use.
>
> But this proposal is about issue tracking anyway: I just point out
> that we already rely on github in spite of its shortcomings.
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de <https://www.thetaphi.de/>

Thanks, Jan for your suggestion - I'd defer the discussion for the options
to contribute from outside GitHub for now, but we'll come back to this
later and we'll find some good ways (if the coming possible vote is passed).

> BWT: All issues, both in JIRA and GitHub are readable to the public
without a user account.

It's good news for me. I haven't browsed GitHub issues without logging in
to it.

Tomoko


2022?5?6?(?) 16:10 Jan Høydahl <jan.asf@cominvent.com>:

> For code changes, patch files in Jira used to be the only option. Over the
> years, this is almost completely replaced by PRs, but we still leave the
> door open for patch in JIRA.
> We could apply the same principle here: Don't shut down JIRA, but change
> documentation so that GitHub issues is documented first. A contributor who
> for some reason is prohibited to use a GitHub account can then use the
> JIRA+patch workflow and CHANGES.txt will record the JIRA issue, in-between
> all the github-issues. BWT: All issues, both in JIRA and GitHub are
> readable to the public without a user account.
>
> Jan
>
> 6. mai 2022 kl. 05:15 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>
> Hi Yuting,
> thanks for your feedback.
> For your information, we have a general issue to improve our contribution
> workflow: LUCENE-10543
> <https://issues.apache.org/jira/browse/LUCENE-10543>, and this is
> actually a sub-task of it.
> You and anyone can contribute to it by leaving comments, creating
> documentation or instruction for developers, or whatever else (if you'd
> like!).
>
> I'll try to keep this thread a safe place for everyone though, I'd
> especially appreciate feedback from newcomers like Vigya and Yuting, since
> I understand and remember it is more difficult (and sometimes fearful) to
> join discussions for new developers than long-time contributors.
>
> Tomoko
>
>
> 2022?5?6?(?) 11:16 Yuti G <gan.yuti@gmail.com>:
>
>> Hi Tomoko,
>>
>> Thanks for raising this discussion!
>>
>> As a new member of the Lucene community, I'm also confused by the input
>> components when creating a Jira issue. I struggled with previewing my text
>> and had to edit it after creating a Jira issue or a comment, and I just
>> found that each re-edit would send an email notification to the list ????
>>
>> I only used the GitHub issue system on a small team scale and
>> I am getting familiar with Jira now. It would be very helpful if we can
>> create a clear instruction/guide for new developers on how to create
>> an issue no matter which system we choose in the future.
>>
>> Best,
>> Yuting
>>
>> On Thu, May 5, 2022 at 6:00 PM Tomoko Uchida <
>> tomoko.uchida.1111@gmail.com> wrote:
>>
>>> I'm not going to thoroughly discuss the migration path from Jira to
>>> GitHub here, but generally, the rough image in my mind is the same as Jan
>>> described - "Milestone" for version tracking, and "labels" for other
>>> purposes (issue types, component types, etc.).
>>>
>>> As for the proposal of in-house GitLab, it could be an option (if UI/UX
>>> is the only problem) but I don't think it's feasible.
>>> We need high availability platform and we don't have machine/human
>>> resources to operate such mission-critical in-house service on our own.
>>> And, even if it's possible, we still have to switch between two platforms -
>>> it doesn't solve my problem.
>>>
>>> > That's precisely the crux of the disagreement: I want to be able to
>>> register
>>> > an account at Apache and *not* GitHub and still be able to contribute.
>>>
>>> > Is the original Jira -> GitHub move just a change of defaults or are
>>> we,
>>> > once moved to GitHub, not letting people use Jira at all anymore ?
>>>
>>> Interesting point - is there anyone else who doesn't have or use GitHub
>>> account and *won't sign up or sign in for it* ?
>>>
>>> Tomoko
>>>
>>>
>>> 2022?5?6?(?) 7:04 Uwe Schindler <uwe@thetaphi.de>:
>>>
>>>> I agree with that.
>>>>
>>>> What annoys me is that I have to open a fake issue in Jira. I think we
>>>> should allow people to open GitHub PR or issues. It gets reported also to
>>>> mailing list. If a Lucene committer does not want to use GitHub, heshe can
>>>> just download the PR as patch file and apply. Same for issues: all is
>>>> mirrored to mailing list.
>>>>
>>>> If our users want to open issues they should do what they prefer.
>>>>
>>>> Uwe
>>>>
>>>> Am 5. Mai 2022 21:50:58 UTC schrieb Michael Sokolov <msokolov@gmail.com
>>>> >:
>>>>>
>>>>> Is the original Jira -> GitHub move just a change of defaults or are we,
>>>>>> once moved to GitHub, not letting people use Jira at all anymore ?
>>>>>>
>>>>>
>>>>> Nothing has been decided - it's all open for debate.
>>>>>
>>>>> I just want to re-state the idea (at least as I heard it) behind this
>>>>> proposed move is to make contributing more accessible.
>>>>>
>>>>> As for github banning people, just google "github banning" and you
>>>>> will see that people have been banned for a variety of reasons.
>>>>>
>>>>> I don't know if the risk of that outweighs the inconvenience of JIRA
>>>>> for the new developer.
>>>>>
>>>>> Please note that the primary avenue for contributions today *is
>>>>> already github*. So far we have not had any issues with people being
>>>>> banned, and if that were to happen, we still accept patch files in
>>>>> JIRA. We have had these two mechanisms in place for quite a while now
>>>>> and both are in active use.
>>>>>
>>>>> But this proposal is about issue tracking anyway: I just point out
>>>>> that we already rely on github in spite of its shortcomings.
>>>>> ------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>> --
>>>> Uwe Schindler
>>>> Achterdiek 19, 28357 Bremen
>>>> https://www.thetaphi.de
>>>>
>>>
>

On Thu, May 5, 2022 at 7:56 AM Robert Muir <rcmuir@gmail.com> wrote:

As far as replies, in github I highlight the part of the thing i want
> to reply to, and press 'r' key on my keyboard. it quotes it and
> everything. Really convenient to me.
>

Whoa, thank you!! I had no idea GitHub has such extensive keyboard
shortcuts (just type ? to see them all).

Mike McCandless

http://blog.mikemccandless.com

I think both tools have their merits and drawbacks

What I like about Jira:

- It has ample room and configuration for issue metadata and
customizable workflows and in general a deep feature set
- It has user roles, PMC members can see security issues that are hidden
from the world...
- I've used it for almost 20 years so It's familiar to me.
- It's hosted at the ASF by the ASF so nobody but the ASF can determine
access or hold it hostage (I think, correct me if I'm wrong and we're now
using atlassian cloud versions).

What Ii do not like about Jira

- They have had LONG standing issues with text and visual mode not
round-tripping (switching between them alters the text and often destroys
formatting) which is something even cheap blogging software usually gets
right.... this is EXTREMELY FRUSTRATING at times where the proper name of
something in code includes an underscore. Especially bad is the fact that
the do provide a way to escape things like underscores but the transition
between visual and text destroys that escaping, making it useless, and if
you carefully set up the escapes in text mode, one small edit by someone
else (perhaps fixing a typo) in visual mode destroys all your hard work!
GRRRR... And of course text mode is sometimes hard to predict so working in
text mode with any non-trivial formatting that you may wind up re-editing
several times which at apache sends multiple emails to the list...
usability nightmare.
- They switched to a default search result layout that wasn't a sortable
table/list. This irritates me because I never want to randomly fill 70% of
the screen with the top hit on a search and have almost no info about all
the other results. Typically I want to immediately sort by issue number to
find recent issues (or older issues depending). Even if text relevancy is
the important thing in my search, assuming the top hit is what I want is
poor.
- By default searches typed in the easily accessed search box run
against every project so then the very first thing I have to do is re-run
with a project filter. Maintaining a project context would be very helpful.
- UI can become cumbersome for filtering on issue fields with many
values (typeahead search presumes you know the name to start with).
- Sometimes slow.

What I like about Github

- It fixes the first and third issue I don't like about jira (edit round
trip and typically has a project context).
- UI updates without explicit refresh
- Generally nice look and feel
- Integration of github actions, pull requests, review, and code
repository is excellent.
- Closing issues via commit message is nice for small projects...

What I don't like about github.

- Very limited and no custom issue metadata
- arbitrary file attachments are not supported. Notably .patch is not
included in their list (GIF, JPEG, JPG, MOV, MP4, PNG, SVG, CSV, DOCX,
FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PDF, PPTX,
TXT, XLS, XLSX or ZIP).
- Search interface for issues is the equivalent of the Jira JQL search
line, and requires learning their syntax for anything but the most basic,
and is:issue must be retained (and wastes space in the small text field) or
it suddenly starts finding non-issues items.
- No concept of workflow (without add/on or plugins).
- Closing issues via commit message is not good where you would want to
ensure review or have any sort of workflow
- It's owned by Microsoft, which while MUCH improved in recent years has
a horrible dark, evil past WRT open source and standards. Above allegations
regarding political banning of individuals is also very troubling and
unfortunately, increasingly relevant in the current global political
landscape.

From the lucene perspective I see some things we have now in Jira that I
don't see a way to maintain in github

- Security issues that are visible to PMC only (more common for solr,
but perhaps needed for lucene sometimes as well)
- Patch review based on an attached patch.
- Accepting patch files instead of pull requests...
- Contribution by folks who for some reason cannot use github (either
blocked by work or github politics or, unwilling to accept githubs
terms/privacy etc.)
- Document with each issue the Affected version and the fixed version.
- While one can create arbitrary labels, they are not segregated into
fields so we would have to put up with what is effectively a single field
for priority, component, and resolution
- No way to enforce that a resolution label is applied to the issue.

I feel that Github issues are simply lacking in depth and riding along on
the virtue of their integrations. I feel like their issue tracking
implementation is a lower priority sideline to their code repository (so
they can say they have it). On the flip side Jira has become hugely
entrenched in the industry and its profits are no-longer tied to innovation
or even usability... and it shows. So I am basically dissatisfied with both
(for most of the last 20 years I've been known to mutter about writing my
own issue tracker... I've not met one that didn't irritate me somehow,
though I haven't actually tried yet, because that's a LOT of work ;) ).

Given how many things I've listed, it's likely something's wrong or
misapprehended, so certainly speak up if I'm just unaware of something in
github.

In the end I don't feel like the benefits of github are worth giving up the
data quality and features that we do actually use in Jira, so I'm -0.9 on
moving to github.

-Gus


On Fri, May 6, 2022 at 11:11 AM Michael McCandless <
lucene@mikemccandless.com> wrote:

> On Thu, May 5, 2022 at 7:56 AM Robert Muir <rcmuir@gmail.com> wrote:
>
> As far as replies, in github I highlight the part of the thing i want
>> to reply to, and press 'r' key on my keyboard. it quotes it and
>> everything. Really convenient to me.
>>
>
> Whoa, thank you!! I had no idea GitHub has such extensive keyboard
> shortcuts (just type ? to see them all).
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>


--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Thanks Gus, for providing the clear pros/cons list and posing an objection.
I welcome constructive criticism that strengthens our discussion.

Among the informative list, I'd highlight a new perspective I haven't seen
so far (and honestly, I haven't considered): Security issues that are
visible to PMC only.
GitHub-inclined people (including me) would need to answer or find
solutions for it if it's an inevitable feature for Lucene. As an obvious
answer, we'll be able to continue to use Jira for such sensitive issues;
but there could be more sophisticated/integrated ways for that?
I'm not knowledgeable about current access control for Jira issues. Does
anyone among the PMC members have an idea - or perhaps we could borrow a
solution from other large/popular projects operated on GitHub (yes,
Elasticsearch and OpenSearch are in my mind).

As for accepting contributions (patches) from developers who don't use
GitHub for some reason, I think we MUST support contribution paths that do
not rely on GitHub PR, and I suppose every committer agrees with me on that.

Tomoko


2022?5?7?(?) 6:46 Gus Heck <gus.heck@gmail.com>:

> I think both tools have their merits and drawbacks
>
> What I like about Jira:
>
> - It has ample room and configuration for issue metadata and
> customizable workflows and in general a deep feature set
> - It has user roles, PMC members can see security issues that are
> hidden from the world...
> - I've used it for almost 20 years so It's familiar to me.
> - It's hosted at the ASF by the ASF so nobody but the ASF can
> determine access or hold it hostage (I think, correct me if I'm wrong
> and we're now using atlassian cloud versions).
>
> What Ii do not like about Jira
>
> - They have had LONG standing issues with text and visual mode not
> round-tripping (switching between them alters the text and often destroys
> formatting) which is something even cheap blogging software usually gets
> right.... this is EXTREMELY FRUSTRATING at times where the proper name of
> something in code includes an underscore. Especially bad is the fact that
> the do provide a way to escape things like underscores but the transition
> between visual and text destroys that escaping, making it useless, and if
> you carefully set up the escapes in text mode, one small edit by someone
> else (perhaps fixing a typo) in visual mode destroys all your hard work!
> GRRRR... And of course text mode is sometimes hard to predict so working in
> text mode with any non-trivial formatting that you may wind up re-editing
> several times which at apache sends multiple emails to the list...
> usability nightmare.
> - They switched to a default search result layout that wasn't a
> sortable table/list. This irritates me because I never want to randomly
> fill 70% of the screen with the top hit on a search and have almost no info
> about all the other results. Typically I want to immediately sort by issue
> number to find recent issues (or older issues depending). Even if text
> relevancy is the important thing in my search, assuming the top hit is what
> I want is poor.
> - By default searches typed in the easily accessed search box run
> against every project so then the very first thing I have to do is re-run
> with a project filter. Maintaining a project context would be very helpful.
> - UI can become cumbersome for filtering on issue fields with many
> values (typeahead search presumes you know the name to start with).
> - Sometimes slow.
>
> What I like about Github
>
> - It fixes the first and third issue I don't like about jira (edit
> round trip and typically has a project context).
> - UI updates without explicit refresh
> - Generally nice look and feel
> - Integration of github actions, pull requests, review, and code
> repository is excellent.
> - Closing issues via commit message is nice for small projects...
>
> What I don't like about github.
>
> - Very limited and no custom issue metadata
> - arbitrary file attachments are not supported. Notably .patch is not
> included in their list (GIF, JPEG, JPG, MOV, MP4, PNG, SVG, CSV, DOCX,
> FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PDF, PPTX,
> TXT, XLS, XLSX or ZIP).
> - Search interface for issues is the equivalent of the Jira JQL search
> line, and requires learning their syntax for anything but the most basic,
> and is:issue must be retained (and wastes space in the small text field) or
> it suddenly starts finding non-issues items.
> - No concept of workflow (without add/on or plugins).
> - Closing issues via commit message is not good where you would want
> to ensure review or have any sort of workflow
> - It's owned by Microsoft, which while MUCH improved in recent years
> has a horrible dark, evil past WRT open source and standards. Above
> allegations regarding political banning of individuals is also very
> troubling and unfortunately, increasingly relevant in the current global
> political landscape.
>
> From the lucene perspective I see some things we have now in Jira that I
> don't see a way to maintain in github
>
> - Security issues that are visible to PMC only (more common for solr,
> but perhaps needed for lucene sometimes as well)
> - Patch review based on an attached patch.
> - Accepting patch files instead of pull requests...
> - Contribution by folks who for some reason cannot use github (either
> blocked by work or github politics or, unwilling to accept githubs
> terms/privacy etc.)
> - Document with each issue the Affected version and the fixed version.
> - While one can create arbitrary labels, they are not segregated into
> fields so we would have to put up with what is effectively a single field
> for priority, component, and resolution
> - No way to enforce that a resolution label is applied to the issue.
>
> I feel that Github issues are simply lacking in depth and riding along on
> the virtue of their integrations. I feel like their issue tracking
> implementation is a lower priority sideline to their code repository (so
> they can say they have it). On the flip side Jira has become hugely
> entrenched in the industry and its profits are no-longer tied to innovation
> or even usability... and it shows. So I am basically dissatisfied with both
> (for most of the last 20 years I've been known to mutter about writing my
> own issue tracker... I've not met one that didn't irritate me somehow,
> though I haven't actually tried yet, because that's a LOT of work ;) ).
>
> Given how many things I've listed, it's likely something's wrong or
> misapprehended, so certainly speak up if I'm just unaware of something in
> github.
>
> In the end I don't feel like the benefits of github are worth giving up
> the data quality and features that we do actually use in Jira, so I'm -0.9
> on moving to github.
>
> -Gus
>
>
> On Fri, May 6, 2022 at 11:11 AM Michael McCandless <
> lucene@mikemccandless.com> wrote:
>
>> On Thu, May 5, 2022 at 7:56 AM Robert Muir <rcmuir@gmail.com> wrote:
>>
>> As far as replies, in github I highlight the part of the thing i want
>>> to reply to, and press 'r' key on my keyboard. it quotes it and
>>> everything. Really convenient to me.
>>>
>>
>> Whoa, thank you!! I had no idea GitHub has such extensive keyboard
>> shortcuts (just type ? to see them all).
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>

> perhaps we could borrow a solution from other large/popular projects
operated on GitHub (yes, Elasticsearch and OpenSearch are in my mind).

FWIW Elasticsearch uses a separate, issue only, private repo with limited
developer access for security issues. I have no idea how feasible that
would be for an ASF project. One thing I like about this is the tight cross
linking of GitHub issues across projects. So if a security issue is opened,
any relevant public issues can be referred to on it. Then the developers
who have access to the security issues can see the back links on the public
issues.

On Fri, May 6, 2022 at 22:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> Thanks Gus, for providing the clear pros/cons list and posing an
> objection. I welcome constructive criticism that strengthens our discussion.
>
> Among the informative list, I'd highlight a new perspective I haven't seen
> so far (and honestly, I haven't considered): Security issues that are
> visible to PMC only.
> GitHub-inclined people (including me) would need to answer or find
> solutions for it if it's an inevitable feature for Lucene. As an obvious
> answer, we'll be able to continue to use Jira for such sensitive issues;
> but there could be more sophisticated/integrated ways for that?
> I'm not knowledgeable about current access control for Jira issues. Does
> anyone among the PMC members have an idea - or perhaps we could borrow a
> solution from other large/popular projects operated on GitHub (yes,
> Elasticsearch and OpenSearch are in my mind).
>
> As for accepting contributions (patches) from developers who don't use
> GitHub for some reason, I think we MUST support contribution paths that do
> not rely on GitHub PR, and I suppose every committer agrees with me on that.
>
> Tomoko
>
>
> 2022?5?7?(?) 6:46 Gus Heck <gus.heck@gmail.com>:
>
>> I think both tools have their merits and drawbacks
>>
>> What I like about Jira:
>>
>> - It has ample room and configuration for issue metadata and
>> customizable workflows and in general a deep feature set
>> - It has user roles, PMC members can see security issues that are
>> hidden from the world...
>> - I've used it for almost 20 years so It's familiar to me.
>> - It's hosted at the ASF by the ASF so nobody but the ASF can
>> determine access or hold it hostage (I think, correct me if I'm wrong
>> and we're now using atlassian cloud versions).
>>
>> What Ii do not like about Jira
>>
>> - They have had LONG standing issues with text and visual mode not
>> round-tripping (switching between them alters the text and often destroys
>> formatting) which is something even cheap blogging software usually gets
>> right.... this is EXTREMELY FRUSTRATING at times where the proper name of
>> something in code includes an underscore. Especially bad is the fact that
>> the do provide a way to escape things like underscores but the transition
>> between visual and text destroys that escaping, making it useless, and if
>> you carefully set up the escapes in text mode, one small edit by someone
>> else (perhaps fixing a typo) in visual mode destroys all your hard work!
>> GRRRR... And of course text mode is sometimes hard to predict so working in
>> text mode with any non-trivial formatting that you may wind up re-editing
>> several times which at apache sends multiple emails to the list...
>> usability nightmare.
>> - They switched to a default search result layout that wasn't a
>> sortable table/list. This irritates me because I never want to randomly
>> fill 70% of the screen with the top hit on a search and have almost no info
>> about all the other results. Typically I want to immediately sort by issue
>> number to find recent issues (or older issues depending). Even if text
>> relevancy is the important thing in my search, assuming the top hit is what
>> I want is poor.
>> - By default searches typed in the easily accessed search box run
>> against every project so then the very first thing I have to do is re-run
>> with a project filter. Maintaining a project context would be very helpful.
>> - UI can become cumbersome for filtering on issue fields with many
>> values (typeahead search presumes you know the name to start with).
>> - Sometimes slow.
>>
>> What I like about Github
>>
>> - It fixes the first and third issue I don't like about jira (edit
>> round trip and typically has a project context).
>> - UI updates without explicit refresh
>> - Generally nice look and feel
>> - Integration of github actions, pull requests, review, and code
>> repository is excellent.
>> - Closing issues via commit message is nice for small projects...
>>
>> What I don't like about github.
>>
>> - Very limited and no custom issue metadata
>> - arbitrary file attachments are not supported. Notably .patch is not
>> included in their list (GIF, JPEG, JPG, MOV, MP4, PNG, SVG, CSV, DOCX,
>> FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PDF, PPTX,
>> TXT, XLS, XLSX or ZIP).
>> - Search interface for issues is the equivalent of the Jira JQL
>> search line, and requires learning their syntax for anything but the most
>> basic, and is:issue must be retained (and wastes space in the small text
>> field) or it suddenly starts finding non-issues items.
>> - No concept of workflow (without add/on or plugins).
>> - Closing issues via commit message is not good where you would want
>> to ensure review or have any sort of workflow
>> - It's owned by Microsoft, which while MUCH improved in recent years
>> has a horrible dark, evil past WRT open source and standards. Above
>> allegations regarding political banning of individuals is also very
>> troubling and unfortunately, increasingly relevant in the current global
>> political landscape.
>>
>> From the lucene perspective I see some things we have now in Jira that I
>> don't see a way to maintain in github
>>
>> - Security issues that are visible to PMC only (more common for solr,
>> but perhaps needed for lucene sometimes as well)
>> - Patch review based on an attached patch.
>> - Accepting patch files instead of pull requests...
>> - Contribution by folks who for some reason cannot use github (either
>> blocked by work or github politics or, unwilling to accept githubs
>> terms/privacy etc.)
>> - Document with each issue the Affected version and the fixed
>> version.
>> - While one can create arbitrary labels, they are not segregated into
>> fields so we would have to put up with what is effectively a single field
>> for priority, component, and resolution
>> - No way to enforce that a resolution label is applied to the issue.
>>
>> I feel that Github issues are simply lacking in depth and riding along on
>> the virtue of their integrations. I feel like their issue tracking
>> implementation is a lower priority sideline to their code repository (so
>> they can say they have it). On the flip side Jira has become hugely
>> entrenched in the industry and its profits are no-longer tied to innovation
>> or even usability... and it shows. So I am basically dissatisfied with both
>> (for most of the last 20 years I've been known to mutter about writing my
>> own issue tracker... I've not met one that didn't irritate me somehow,
>> though I haven't actually tried yet, because that's a LOT of work ;) ).
>>
>> Given how many things I've listed, it's likely something's wrong or
>> misapprehended, so certainly speak up if I'm just unaware of something in
>> github.
>>
>> In the end I don't feel like the benefits of github are worth giving up
>> the data quality and features that we do actually use in Jira, so I'm -0.9
>> on moving to github.
>>
>> -Gus
>>
>>
>> On Fri, May 6, 2022 at 11:11 AM Michael McCandless <
>> lucene@mikemccandless.com> wrote:
>>
>>> On Thu, May 5, 2022 at 7:56 AM Robert Muir <rcmuir@gmail.com> wrote:
>>>
>>> As far as replies, in github I highlight the part of the thing i want
>>>> to reply to, and press 'r' key on my keyboard. it quotes it and
>>>> everything. Really convenient to me.
>>>>
>>>
>>> Whoa, thank you!! I had no idea GitHub has such extensive keyboard
>>> shortcuts (just type ? to see them all).
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>

Many of my opinions have been expressed, and of course my (non-binding)
vote for switching to GitHub issues is of little to no consequence.

I wish to acknowledge and yet respond to Gus's reasonable objection to
switching to GitHub in addition to a few other comments.

It's owned by Microsoft


I feel it would be wholly damaging to the Microsoft brand to pull the rug
under the many open source projects owned by non-profits and hosted
entirely on GitHub. Their leadership is trending toward the good and any
absurd actions like that would have very serious ramifications for their
business. I think it's a non-issue for the foreseeable future that is
outweighed by the benefits of shedding Jira. Furthermore, here's a short
list of tutorials
<https://gist.github.com/MarcusSorealheis/c3e5055442b89fdf0d32c392e95ea314> for
migrating back to Jira in a doomsday scenario.


> - No way to enforce that a resolution label is applied to the issue.
>
> We can enforce labels. It will require some customization to some of the
existing options. Here is a popular one
<https://github.com/marketplace/actions/require-labels>.


> - Document with each issue the Affected version and the fixed version.
>
> There are many ways to do this one. The simplest is the issue template
<https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository>.
There are many others, though.

Jira is very robust, but it is daunting. It seems that to make this
proposal viable, a few members of the community need to commit to setting
up and facilitating the transition. To me, it feels like a two month
effort.

Regarding .patch files, I think there are very few systems that still rely
on them. However, there are some projects out there that could add support
for ,patch files via email. I did not look into it too much but I did
comment on one project's issue requesting such support. I'm not totally
sure about what's happening with the project or that feature request. I'm
mostly hoping to elicit more details.

I respect .patch and Jira. Ultimately, I despise how annoying Jira gets and
think that more developers could get involved if we removed that
dependency. GitHub actions give us lots of customizability.

Best,

Marcus

On Sun, May 8, 2022 at 8:38 AM Ryan Ernst <ryan@iernst.net> wrote:

> > perhaps we could borrow a solution from other large/popular projects
> operated on GitHub (yes, Elasticsearch and OpenSearch are in my mind).
>
> FWIW Elasticsearch uses a separate, issue only, private repo with limited
> developer access for security issues. I have no idea how feasible that
> would be for an ASF project. One thing I like about this is the tight cross
> linking of GitHub issues across projects. So if a security issue is opened,
> any relevant public issues can be referred to on it. Then the developers
> who have access to the security issues can see the back links on the public
> issues.
>
> On Fri, May 6, 2022 at 22:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>
> wrote:
>
>> Thanks Gus, for providing the clear pros/cons list and posing an
>> objection. I welcome constructive criticism that strengthens our discussion.
>>
>> Among the informative list, I'd highlight a new perspective I haven't
>> seen so far (and honestly, I haven't considered): Security issues that are
>> visible to PMC only.
>> GitHub-inclined people (including me) would need to answer or find
>> solutions for it if it's an inevitable feature for Lucene. As an obvious
>> answer, we'll be able to continue to use Jira for such sensitive issues;
>> but there could be more sophisticated/integrated ways for that?
>> I'm not knowledgeable about current access control for Jira issues. Does
>> anyone among the PMC members have an idea - or perhaps we could borrow a
>> solution from other large/popular projects operated on GitHub (yes,
>> Elasticsearch and OpenSearch are in my mind).
>>
>> As for accepting contributions (patches) from developers who don't use
>> GitHub for some reason, I think we MUST support contribution paths that do
>> not rely on GitHub PR, and I suppose every committer agrees with me on that.
>>
>> Tomoko
>>
>>
>> 2022?5?7?(?) 6:46 Gus Heck <gus.heck@gmail.com>:
>>
>>> I think both tools have their merits and drawbacks
>>>
>>> What I like about Jira:
>>>
>>> - It has ample room and configuration for issue metadata and
>>> customizable workflows and in general a deep feature set
>>> - It has user roles, PMC members can see security issues that are
>>> hidden from the world...
>>> - I've used it for almost 20 years so It's familiar to me.
>>> - It's hosted at the ASF by the ASF so nobody but the ASF can
>>> determine access or hold it hostage (I think, correct me if I'm wrong
>>> and we're now using atlassian cloud versions).
>>>
>>> What Ii do not like about Jira
>>>
>>> - They have had LONG standing issues with text and visual mode not
>>> round-tripping (switching between them alters the text and often destroys
>>> formatting) which is something even cheap blogging software usually gets
>>> right.... this is EXTREMELY FRUSTRATING at times where the proper name of
>>> something in code includes an underscore. Especially bad is the fact that
>>> the do provide a way to escape things like underscores but the transition
>>> between visual and text destroys that escaping, making it useless, and if
>>> you carefully set up the escapes in text mode, one small edit by someone
>>> else (perhaps fixing a typo) in visual mode destroys all your hard work!
>>> GRRRR... And of course text mode is sometimes hard to predict so working in
>>> text mode with any non-trivial formatting that you may wind up re-editing
>>> several times which at apache sends multiple emails to the list...
>>> usability nightmare.
>>> - They switched to a default search result layout that wasn't a
>>> sortable table/list. This irritates me because I never want to randomly
>>> fill 70% of the screen with the top hit on a search and have almost no info
>>> about all the other results. Typically I want to immediately sort by issue
>>> number to find recent issues (or older issues depending). Even if text
>>> relevancy is the important thing in my search, assuming the top hit is what
>>> I want is poor.
>>> - By default searches typed in the easily accessed search box run
>>> against every project so then the very first thing I have to do is re-run
>>> with a project filter. Maintaining a project context would be very helpful.
>>> - UI can become cumbersome for filtering on issue fields with many
>>> values (typeahead search presumes you know the name to start with).
>>> - Sometimes slow.
>>>
>>> What I like about Github
>>>
>>> - It fixes the first and third issue I don't like about jira (edit
>>> round trip and typically has a project context).
>>> - UI updates without explicit refresh
>>> - Generally nice look and feel
>>> - Integration of github actions, pull requests, review, and code
>>> repository is excellent.
>>> - Closing issues via commit message is nice for small projects...
>>>
>>> What I don't like about github.
>>>
>>> - Very limited and no custom issue metadata
>>> - arbitrary file attachments are not supported. Notably .patch is
>>> not included in their list (GIF, JPEG, JPG, MOV, MP4, PNG, SVG, CSV, DOCX,
>>> FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PDF, PPTX,
>>> TXT, XLS, XLSX or ZIP).
>>> - Search interface for issues is the equivalent of the Jira JQL
>>> search line, and requires learning their syntax for anything but the most
>>> basic, and is:issue must be retained (and wastes space in the small text
>>> field) or it suddenly starts finding non-issues items.
>>> - No concept of workflow (without add/on or plugins).
>>> - Closing issues via commit message is not good where you would want
>>> to ensure review or have any sort of workflow
>>> - It's owned by Microsoft, which while MUCH improved in recent years
>>> has a horrible dark, evil past WRT open source and standards. Above
>>> allegations regarding political banning of individuals is also very
>>> troubling and unfortunately, increasingly relevant in the current global
>>> political landscape.
>>>
>>> From the lucene perspective I see some things we have now in Jira that I
>>> don't see a way to maintain in github
>>>
>>> - Security issues that are visible to PMC only (more common for
>>> solr, but perhaps needed for lucene sometimes as well)
>>> - Patch review based on an attached patch.
>>> - Accepting patch files instead of pull requests...
>>> - Contribution by folks who for some reason cannot use github
>>> (either blocked by work or github politics or, unwilling to accept githubs
>>> terms/privacy etc.)
>>> - Document with each issue the Affected version and the fixed
>>> version.
>>> - While one can create arbitrary labels, they are not segregated
>>> into fields so we would have to put up with what is effectively a single
>>> field for priority, component, and resolution
>>> - No way to enforce that a resolution label is applied to the issue.
>>>
>>> I feel that Github issues are simply lacking in depth and riding along
>>> on the virtue of their integrations. I feel like their issue tracking
>>> implementation is a lower priority sideline to their code repository (so
>>> they can say they have it). On the flip side Jira has become hugely
>>> entrenched in the industry and its profits are no-longer tied to innovation
>>> or even usability... and it shows. So I am basically dissatisfied with both
>>> (for most of the last 20 years I've been known to mutter about writing my
>>> own issue tracker... I've not met one that didn't irritate me somehow,
>>> though I haven't actually tried yet, because that's a LOT of work ;) ).
>>>
>>> Given how many things I've listed, it's likely something's wrong or
>>> misapprehended, so certainly speak up if I'm just unaware of something in
>>> github.
>>>
>>> In the end I don't feel like the benefits of github are worth giving up
>>> the data quality and features that we do actually use in Jira, so I'm -0.9
>>> on moving to github.
>>>
>>> -Gus
>>>
>>>
>>> On Fri, May 6, 2022 at 11:11 AM Michael McCandless <
>>> lucene@mikemccandless.com> wrote:
>>>
>>>> On Thu, May 5, 2022 at 7:56 AM Robert Muir <rcmuir@gmail.com> wrote:
>>>>
>>>> As far as replies, in github I highlight the part of the thing i want
>>>>> to reply to, and press 'r' key on my keyboard. it quotes it and
>>>>> everything. Really convenient to me.
>>>>>
>>>>
>>>> Whoa, thank you!! I had no idea GitHub has such extensive keyboard
>>>> shortcuts (just type ? to see them all).
>>>>
>>>> Mike McCandless
>>>>
>>>> http://blog.mikemccandless.com
>>>>
>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>

--
Marcus Eagan

Hi Marcus,

> Many of my opinions have been expressed, and of course my (non-binding)
vote for switching to GitHub issues is of little to no consequence.

Although only PMC members' votes are counted (binding) [1], feedback from
the whole community is absolutely essential for such changes; and it may
change the vote result. :)

[1] https://www.apache.org/foundation/voting.html

> FWIW Elasticsearch uses a separate, issue only, private repo with limited
developer access for security issues. I have no idea how feasible that
would be for an ASF project. One thing I like about this is the tight cross
linking of GitHub issues across projects. So if a security issue is opened,
any relevant public issues can be referred to on it. Then the developers
who have access to the security issues can see the back links on the public
issues.

Thank you Ryan, an issue-only private repository sounds good to me if it is
allowed to have one for Lucene TLP.

I don't even know how many "private" issues are there, let me consult with
PMC members on how to handle it when it's supposed to be; I'll keep it on
the to-do list.

Thanks,
Tomoko


2022?5?9?(?) 12:51 Marcus Eagan <marcuseagan@gmail.com>:

> Many of my opinions have been expressed, and of course my (non-binding)
> vote for switching to GitHub issues is of little to no consequence.
>
> I wish to acknowledge and yet respond to Gus's reasonable objection to
> switching to GitHub in addition to a few other comments.
>
> It's owned by Microsoft
>
>
> I feel it would be wholly damaging to the Microsoft brand to pull the rug
> under the many open source projects owned by non-profits and hosted
> entirely on GitHub. Their leadership is trending toward the good and any
> absurd actions like that would have very serious ramifications for their
> business. I think it's a non-issue for the foreseeable future that is
> outweighed by the benefits of shedding Jira. Furthermore, here's a short
> list of tutorials
> <https://gist.github.com/MarcusSorealheis/c3e5055442b89fdf0d32c392e95ea314> for
> migrating back to Jira in a doomsday scenario.
>
>
>> - No way to enforce that a resolution label is applied to the issue.
>>
>> We can enforce labels. It will require some customization to some of the
> existing options. Here is a popular one
> <https://github.com/marketplace/actions/require-labels>.
>
>
>> - Document with each issue the Affected version and the fixed
>> version.
>>
>> There are many ways to do this one. The simplest is the issue template
> <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository>.
> There are many others, though.
>
> Jira is very robust, but it is daunting. It seems that to make this
> proposal viable, a few members of the community need to commit to setting
> up and facilitating the transition. To me, it feels like a two month
> effort.
>
> Regarding .patch files, I think there are very few systems that still rely
> on them. However, there are some projects out there that could add support
> for ,patch files via email. I did not look into it too much but I did
> comment on one project's issue requesting such support. I'm not totally
> sure about what's happening with the project or that feature request. I'm
> mostly hoping to elicit more details.
>
> I respect .patch and Jira. Ultimately, I despise how annoying Jira gets
> and think that more developers could get involved if we removed that
> dependency. GitHub actions give us lots of customizability.
>
> Best,
>
> Marcus
>
> On Sun, May 8, 2022 at 8:38 AM Ryan Ernst <ryan@iernst.net> wrote:
>
>> > perhaps we could borrow a solution from other large/popular projects
>> operated on GitHub (yes, Elasticsearch and OpenSearch are in my mind).
>>
>> FWIW Elasticsearch uses a separate, issue only, private repo with limited
>> developer access for security issues. I have no idea how feasible that
>> would be for an ASF project. One thing I like about this is the tight cross
>> linking of GitHub issues across projects. So if a security issue is opened,
>> any relevant public issues can be referred to on it. Then the developers
>> who have access to the security issues can see the back links on the public
>> issues.
>>
>> On Fri, May 6, 2022 at 22:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>
>> wrote:
>>
>>> Thanks Gus, for providing the clear pros/cons list and posing an
>>> objection. I welcome constructive criticism that strengthens our discussion.
>>>
>>> Among the informative list, I'd highlight a new perspective I haven't
>>> seen so far (and honestly, I haven't considered): Security issues that are
>>> visible to PMC only.
>>> GitHub-inclined people (including me) would need to answer or find
>>> solutions for it if it's an inevitable feature for Lucene. As an obvious
>>> answer, we'll be able to continue to use Jira for such sensitive issues;
>>> but there could be more sophisticated/integrated ways for that?
>>> I'm not knowledgeable about current access control for Jira issues. Does
>>> anyone among the PMC members have an idea - or perhaps we could borrow a
>>> solution from other large/popular projects operated on GitHub (yes,
>>> Elasticsearch and OpenSearch are in my mind).
>>>
>>> As for accepting contributions (patches) from developers who don't use
>>> GitHub for some reason, I think we MUST support contribution paths that do
>>> not rely on GitHub PR, and I suppose every committer agrees with me on that.
>>>
>>> Tomoko
>>>
>>>
>>> 2022?5?7?(?) 6:46 Gus Heck <gus.heck@gmail.com>:
>>>
>>>> I think both tools have their merits and drawbacks
>>>>
>>>> What I like about Jira:
>>>>
>>>> - It has ample room and configuration for issue metadata and
>>>> customizable workflows and in general a deep feature set
>>>> - It has user roles, PMC members can see security issues that are
>>>> hidden from the world...
>>>> - I've used it for almost 20 years so It's familiar to me.
>>>> - It's hosted at the ASF by the ASF so nobody but the ASF can
>>>> determine access or hold it hostage (I think, correct me if I'm wrong
>>>> and we're now using atlassian cloud versions).
>>>>
>>>> What Ii do not like about Jira
>>>>
>>>> - They have had LONG standing issues with text and visual mode not
>>>> round-tripping (switching between them alters the text and often destroys
>>>> formatting) which is something even cheap blogging software usually gets
>>>> right.... this is EXTREMELY FRUSTRATING at times where the proper name of
>>>> something in code includes an underscore. Especially bad is the fact that
>>>> the do provide a way to escape things like underscores but the transition
>>>> between visual and text destroys that escaping, making it useless, and if
>>>> you carefully set up the escapes in text mode, one small edit by someone
>>>> else (perhaps fixing a typo) in visual mode destroys all your hard work!
>>>> GRRRR... And of course text mode is sometimes hard to predict so working in
>>>> text mode with any non-trivial formatting that you may wind up re-editing
>>>> several times which at apache sends multiple emails to the list...
>>>> usability nightmare.
>>>> - They switched to a default search result layout that wasn't a
>>>> sortable table/list. This irritates me because I never want to randomly
>>>> fill 70% of the screen with the top hit on a search and have almost no info
>>>> about all the other results. Typically I want to immediately sort by issue
>>>> number to find recent issues (or older issues depending). Even if text
>>>> relevancy is the important thing in my search, assuming the top hit is what
>>>> I want is poor.
>>>> - By default searches typed in the easily accessed search box run
>>>> against every project so then the very first thing I have to do is re-run
>>>> with a project filter. Maintaining a project context would be very helpful.
>>>> - UI can become cumbersome for filtering on issue fields with many
>>>> values (typeahead search presumes you know the name to start with).
>>>> - Sometimes slow.
>>>>
>>>> What I like about Github
>>>>
>>>> - It fixes the first and third issue I don't like about jira (edit
>>>> round trip and typically has a project context).
>>>> - UI updates without explicit refresh
>>>> - Generally nice look and feel
>>>> - Integration of github actions, pull requests, review, and code
>>>> repository is excellent.
>>>> - Closing issues via commit message is nice for small projects...
>>>>
>>>> What I don't like about github.
>>>>
>>>> - Very limited and no custom issue metadata
>>>> - arbitrary file attachments are not supported. Notably .patch is
>>>> not included in their list (GIF, JPEG, JPG, MOV, MP4, PNG, SVG, CSV, DOCX,
>>>> FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PDF, PPTX,
>>>> TXT, XLS, XLSX or ZIP).
>>>> - Search interface for issues is the equivalent of the Jira JQL
>>>> search line, and requires learning their syntax for anything but the most
>>>> basic, and is:issue must be retained (and wastes space in the small text
>>>> field) or it suddenly starts finding non-issues items.
>>>> - No concept of workflow (without add/on or plugins).
>>>> - Closing issues via commit message is not good where you would
>>>> want to ensure review or have any sort of workflow
>>>> - It's owned by Microsoft, which while MUCH improved in recent
>>>> years has a horrible dark, evil past WRT open source and standards. Above
>>>> allegations regarding political banning of individuals is also very
>>>> troubling and unfortunately, increasingly relevant in the current global
>>>> political landscape.
>>>>
>>>> From the lucene perspective I see some things we have now in Jira that
>>>> I don't see a way to maintain in github
>>>>
>>>> - Security issues that are visible to PMC only (more common for
>>>> solr, but perhaps needed for lucene sometimes as well)
>>>> - Patch review based on an attached patch.
>>>> - Accepting patch files instead of pull requests...
>>>> - Contribution by folks who for some reason cannot use github
>>>> (either blocked by work or github politics or, unwilling to accept githubs
>>>> terms/privacy etc.)
>>>> - Document with each issue the Affected version and the fixed
>>>> version.
>>>> - While one can create arbitrary labels, they are not segregated
>>>> into fields so we would have to put up with what is effectively a single
>>>> field for priority, component, and resolution
>>>> - No way to enforce that a resolution label is applied to the issue.
>>>>
>>>> I feel that Github issues are simply lacking in depth and riding along
>>>> on the virtue of their integrations. I feel like their issue tracking
>>>> implementation is a lower priority sideline to their code repository (so
>>>> they can say they have it). On the flip side Jira has become hugely
>>>> entrenched in the industry and its profits are no-longer tied to innovation
>>>> or even usability... and it shows. So I am basically dissatisfied with both
>>>> (for most of the last 20 years I've been known to mutter about writing my
>>>> own issue tracker... I've not met one that didn't irritate me somehow,
>>>> though I haven't actually tried yet, because that's a LOT of work ;) ).
>>>>
>>>> Given how many things I've listed, it's likely something's wrong or
>>>> misapprehended, so certainly speak up if I'm just unaware of something in
>>>> github.
>>>>
>>>> In the end I don't feel like the benefits of github are worth giving up
>>>> the data quality and features that we do actually use in Jira, so I'm -0.9
>>>> on moving to github.
>>>>
>>>> -Gus
>>>>
>>>>
>>>> On Fri, May 6, 2022 at 11:11 AM Michael McCandless <
>>>> lucene@mikemccandless.com> wrote:
>>>>
>>>>> On Thu, May 5, 2022 at 7:56 AM Robert Muir <rcmuir@gmail.com> wrote:
>>>>>
>>>>> As far as replies, in github I highlight the part of the thing i want
>>>>>> to reply to, and press 'r' key on my keyboard. it quotes it and
>>>>>> everything. Really convenient to me.
>>>>>>
>>>>>
>>>>> Whoa, thank you!! I had no idea GitHub has such extensive keyboard
>>>>> shortcuts (just type ? to see them all).
>>>>>
>>>>> Mike McCandless
>>>>>
>>>>> http://blog.mikemccandless.com
>>>>>
>>>>
>>>>
>>>> --
>>>> http://www.needhamsoftware.com (work)
>>>> http://www.the111shift.com (play)
>>>>
>>>
>
> --
> Marcus Eagan
>
>

> It seems that to make this proposal viable, a few members of the
community need to commit to setting up and facilitating the transition. To
me, it feels like a two month effort.

I'm not going to intensely discuss how the transition will be (should be)
done on this thread though, it'd be important we are confident that it's
feasible and we can complete it in a certain time span (two months could be
a good estimation, I think) before starting a vote.
I'll make a list of matters we have seen so far and present a draft
transition plan before wrapping up the discuss thread. If anyone notices
that we overlook something important, it'd be helpful to point out that to
make the draft plan practical.

Tomoko


2022?5?9?(?) 16:06 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:

> Hi Marcus,
>
> > Many of my opinions have been expressed, and of course my (non-binding)
> vote for switching to GitHub issues is of little to no consequence.
>
> Although only PMC members' votes are counted (binding) [1], feedback from
> the whole community is absolutely essential for such changes; and it may
> change the vote result. :)
>
> [1] https://www.apache.org/foundation/voting.html
>
> > FWIW Elasticsearch uses a separate, issue only, private repo with
> limited developer access for security issues. I have no idea how feasible
> that would be for an ASF project. One thing I like about this is the tight
> cross linking of GitHub issues across projects. So if a security issue is
> opened, any relevant public issues can be referred to on it. Then the
> developers who have access to the security issues can see the back links on
> the public issues.
>
> Thank you Ryan, an issue-only private repository sounds good to me if it
> is allowed to have one for Lucene TLP.
>
> I don't even know how many "private" issues are there, let me consult with
> PMC members on how to handle it when it's supposed to be; I'll keep it on
> the to-do list.
>
> Thanks,
> Tomoko
>
>
> 2022?5?9?(?) 12:51 Marcus Eagan <marcuseagan@gmail.com>:
>
>> Many of my opinions have been expressed, and of course my (non-binding)
>> vote for switching to GitHub issues is of little to no consequence.
>>
>> I wish to acknowledge and yet respond to Gus's reasonable objection to
>> switching to GitHub in addition to a few other comments.
>>
>> It's owned by Microsoft
>>
>>
>> I feel it would be wholly damaging to the Microsoft brand to pull the rug
>> under the many open source projects owned by non-profits and hosted
>> entirely on GitHub. Their leadership is trending toward the good and any
>> absurd actions like that would have very serious ramifications for their
>> business. I think it's a non-issue for the foreseeable future that is
>> outweighed by the benefits of shedding Jira. Furthermore, here's a short
>> list of tutorials
>> <https://gist.github.com/MarcusSorealheis/c3e5055442b89fdf0d32c392e95ea314> for
>> migrating back to Jira in a doomsday scenario.
>>
>>
>>> - No way to enforce that a resolution label is applied to the issue.
>>>
>>> We can enforce labels. It will require some customization to some of the
>> existing options. Here is a popular one
>> <https://github.com/marketplace/actions/require-labels>.
>>
>>
>>> - Document with each issue the Affected version and the fixed
>>> version.
>>>
>>> There are many ways to do this one. The simplest is the issue template
>> <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository>.
>> There are many others, though.
>>
>> Jira is very robust, but it is daunting. It seems that to make this
>> proposal viable, a few members of the community need to commit to setting
>> up and facilitating the transition. To me, it feels like a two month
>> effort.
>>
>> Regarding .patch files, I think there are very few systems that still
>> rely on them. However, there are some projects out there that could add
>> support for ,patch files via email. I did not look into it too much but I
>> did comment on one project's issue requesting such support. I'm not totally
>> sure about what's happening with the project or that feature request. I'm
>> mostly hoping to elicit more details.
>>
>> I respect .patch and Jira. Ultimately, I despise how annoying Jira gets
>> and think that more developers could get involved if we removed that
>> dependency. GitHub actions give us lots of customizability.
>>
>> Best,
>>
>> Marcus
>>
>> On Sun, May 8, 2022 at 8:38 AM Ryan Ernst <ryan@iernst.net> wrote:
>>
>>> > perhaps we could borrow a solution from other large/popular projects
>>> operated on GitHub (yes, Elasticsearch and OpenSearch are in my mind).
>>>
>>> FWIW Elasticsearch uses a separate, issue only, private repo with
>>> limited developer access for security issues. I have no idea how feasible
>>> that would be for an ASF project. One thing I like about this is the tight
>>> cross linking of GitHub issues across projects. So if a security issue is
>>> opened, any relevant public issues can be referred to on it. Then the
>>> developers who have access to the security issues can see the back links on
>>> the public issues.
>>>
>>> On Fri, May 6, 2022 at 22:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>
>>> wrote:
>>>
>>>> Thanks Gus, for providing the clear pros/cons list and posing an
>>>> objection. I welcome constructive criticism that strengthens our discussion.
>>>>
>>>> Among the informative list, I'd highlight a new perspective I haven't
>>>> seen so far (and honestly, I haven't considered): Security issues that are
>>>> visible to PMC only.
>>>> GitHub-inclined people (including me) would need to answer or find
>>>> solutions for it if it's an inevitable feature for Lucene. As an obvious
>>>> answer, we'll be able to continue to use Jira for such sensitive issues;
>>>> but there could be more sophisticated/integrated ways for that?
>>>> I'm not knowledgeable about current access control for Jira issues.
>>>> Does anyone among the PMC members have an idea - or perhaps we could borrow
>>>> a solution from other large/popular projects operated on GitHub (yes,
>>>> Elasticsearch and OpenSearch are in my mind).
>>>>
>>>> As for accepting contributions (patches) from developers who don't use
>>>> GitHub for some reason, I think we MUST support contribution paths that do
>>>> not rely on GitHub PR, and I suppose every committer agrees with me on that.
>>>>
>>>> Tomoko
>>>>
>>>>
>>>> 2022?5?7?(?) 6:46 Gus Heck <gus.heck@gmail.com>:
>>>>
>>>>> I think both tools have their merits and drawbacks
>>>>>
>>>>> What I like about Jira:
>>>>>
>>>>> - It has ample room and configuration for issue metadata and
>>>>> customizable workflows and in general a deep feature set
>>>>> - It has user roles, PMC members can see security issues that are
>>>>> hidden from the world...
>>>>> - I've used it for almost 20 years so It's familiar to me.
>>>>> - It's hosted at the ASF by the ASF so nobody but the ASF can
>>>>> determine access or hold it hostage (I think, correct me if I'm wrong
>>>>> and we're now using atlassian cloud versions).
>>>>>
>>>>> What Ii do not like about Jira
>>>>>
>>>>> - They have had LONG standing issues with text and visual mode not
>>>>> round-tripping (switching between them alters the text and often destroys
>>>>> formatting) which is something even cheap blogging software usually gets
>>>>> right.... this is EXTREMELY FRUSTRATING at times where the proper name of
>>>>> something in code includes an underscore. Especially bad is the fact that
>>>>> the do provide a way to escape things like underscores but the transition
>>>>> between visual and text destroys that escaping, making it useless, and if
>>>>> you carefully set up the escapes in text mode, one small edit by someone
>>>>> else (perhaps fixing a typo) in visual mode destroys all your hard work!
>>>>> GRRRR... And of course text mode is sometimes hard to predict so working in
>>>>> text mode with any non-trivial formatting that you may wind up re-editing
>>>>> several times which at apache sends multiple emails to the list...
>>>>> usability nightmare.
>>>>> - They switched to a default search result layout that wasn't a
>>>>> sortable table/list. This irritates me because I never want to randomly
>>>>> fill 70% of the screen with the top hit on a search and have almost no info
>>>>> about all the other results. Typically I want to immediately sort by issue
>>>>> number to find recent issues (or older issues depending). Even if text
>>>>> relevancy is the important thing in my search, assuming the top hit is what
>>>>> I want is poor.
>>>>> - By default searches typed in the easily accessed search box run
>>>>> against every project so then the very first thing I have to do is re-run
>>>>> with a project filter. Maintaining a project context would be very helpful.
>>>>> - UI can become cumbersome for filtering on issue fields with many
>>>>> values (typeahead search presumes you know the name to start with).
>>>>> - Sometimes slow.
>>>>>
>>>>> What I like about Github
>>>>>
>>>>> - It fixes the first and third issue I don't like about jira (edit
>>>>> round trip and typically has a project context).
>>>>> - UI updates without explicit refresh
>>>>> - Generally nice look and feel
>>>>> - Integration of github actions, pull requests, review, and code
>>>>> repository is excellent.
>>>>> - Closing issues via commit message is nice for small projects...
>>>>>
>>>>> What I don't like about github.
>>>>>
>>>>> - Very limited and no custom issue metadata
>>>>> - arbitrary file attachments are not supported. Notably .patch is
>>>>> not included in their list (GIF, JPEG, JPG, MOV, MP4, PNG, SVG, CSV, DOCX,
>>>>> FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PDF, PPTX,
>>>>> TXT, XLS, XLSX or ZIP).
>>>>> - Search interface for issues is the equivalent of the Jira JQL
>>>>> search line, and requires learning their syntax for anything but the most
>>>>> basic, and is:issue must be retained (and wastes space in the small text
>>>>> field) or it suddenly starts finding non-issues items.
>>>>> - No concept of workflow (without add/on or plugins).
>>>>> - Closing issues via commit message is not good where you would
>>>>> want to ensure review or have any sort of workflow
>>>>> - It's owned by Microsoft, which while MUCH improved in recent
>>>>> years has a horrible dark, evil past WRT open source and standards. Above
>>>>> allegations regarding political banning of individuals is also very
>>>>> troubling and unfortunately, increasingly relevant in the current global
>>>>> political landscape.
>>>>>
>>>>> From the lucene perspective I see some things we have now in Jira that
>>>>> I don't see a way to maintain in github
>>>>>
>>>>> - Security issues that are visible to PMC only (more common for
>>>>> solr, but perhaps needed for lucene sometimes as well)
>>>>> - Patch review based on an attached patch.
>>>>> - Accepting patch files instead of pull requests...
>>>>> - Contribution by folks who for some reason cannot use github
>>>>> (either blocked by work or github politics or, unwilling to accept githubs
>>>>> terms/privacy etc.)
>>>>> - Document with each issue the Affected version and the fixed
>>>>> version.
>>>>> - While one can create arbitrary labels, they are not segregated
>>>>> into fields so we would have to put up with what is effectively a single
>>>>> field for priority, component, and resolution
>>>>> - No way to enforce that a resolution label is applied to the
>>>>> issue.
>>>>>
>>>>> I feel that Github issues are simply lacking in depth and riding along
>>>>> on the virtue of their integrations. I feel like their issue tracking
>>>>> implementation is a lower priority sideline to their code repository (so
>>>>> they can say they have it). On the flip side Jira has become hugely
>>>>> entrenched in the industry and its profits are no-longer tied to innovation
>>>>> or even usability... and it shows. So I am basically dissatisfied with both
>>>>> (for most of the last 20 years I've been known to mutter about writing my
>>>>> own issue tracker... I've not met one that didn't irritate me somehow,
>>>>> though I haven't actually tried yet, because that's a LOT of work ;) ).
>>>>>
>>>>> Given how many things I've listed, it's likely something's wrong or
>>>>> misapprehended, so certainly speak up if I'm just unaware of something in
>>>>> github.
>>>>>
>>>>> In the end I don't feel like the benefits of github are worth giving
>>>>> up the data quality and features that we do actually use in Jira, so I'm
>>>>> -0.9 on moving to github.
>>>>>
>>>>> -Gus
>>>>>
>>>>>
>>>>> On Fri, May 6, 2022 at 11:11 AM Michael McCandless <
>>>>> lucene@mikemccandless.com> wrote:
>>>>>
>>>>>> On Thu, May 5, 2022 at 7:56 AM Robert Muir <rcmuir@gmail.com> wrote:
>>>>>>
>>>>>> As far as replies, in github I highlight the part of the thing i want
>>>>>>> to reply to, and press 'r' key on my keyboard. it quotes it and
>>>>>>> everything. Really convenient to me.
>>>>>>>
>>>>>>
>>>>>> Whoa, thank you!! I had no idea GitHub has such extensive keyboard
>>>>>> shortcuts (just type ? to see them all).
>>>>>>
>>>>>> Mike McCandless
>>>>>>
>>>>>> http://blog.mikemccandless.com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.needhamsoftware.com (work)
>>>>> http://www.the111shift.com (play)
>>>>>
>>>>
>>
>> --
>> Marcus Eagan
>>
>>

On the suggestion of private security only repo in another mail... that
seems to mean security issues can never be made public? Presently we have a
culture of openness where once the issue is resolved and a fix release we
share the discussion. I think that's good since it can then lead security
researchers or others to test our fix better and users can better
understand why we had to remove something or whatever.

responses inline

On Sun, May 8, 2022 at 11:51 PM Marcus Eagan <marcuseagan@gmail.com> wrote:

> Many of my opinions have been expressed, and of course my (non-binding)
> vote for switching to GitHub issues is of little to no consequence.
>
>
Binding votes are not the only important votes, as Tomoko pointed out.


> I feel it would be wholly damaging to the Microsoft brand to pull the rug
> under the many open source projects owned by non-profits and hosted
> entirely on GitHub. Their leadership is trending toward the good and any
> absurd actions like that would have very serious ramifications for their
> business. I think it's a non-issue for the foreseeable future that is
> outweighed by the benefits of shedding Jira. Furthermore, here's a short
> list of tutorials
> <https://gist.github.com/MarcusSorealheis/c3e5055442b89fdf0d32c392e95ea314> for
> migrating back to Jira in a doomsday scenario.
>

I don't disagree, and I acknowledge that the recent trend is much improved,
but It's a lever by which an external company motivated by profit can
disrupt us if it happens to be in their interest. (besides profit, there
could be political motives etc, Imagine prominent pmc members expose a flaw
that really hurts them or sign some sort of open letter in favor of a
political candidate that explicitly wants to target them with antitrust
laws... not that happens anymore in the US but nevermind... ).

I have a bias for the ASF and its projects to be self-sufficient
where feasible, and while loss of donations would be an issue
regardless, that would have to be at the ASF level and couldn't target
specific projects or individuals making it far less attractive. One can
argue that the irritations in Jira are making it infeasible, but that's my
bias.


>
>> - No way to enforce that a resolution label is applied to the issue.
>>
>> We can enforce labels. It will require some customization to some of the
> existing options. Here is a popular one
> <https://github.com/marketplace/actions/require-labels>.
>

Hmm those are labels on PR's not issues. Github does not have an issue/pr
direct linking

Which reminds me I don't think there's a way to link issues such as "this
one blocks that one" or "This one is related to that one", etc.


>
>
>> - Document with each issue the Affected version and the fixed
>> version.
>>
>> There are many ways to do this one. The simplest is the issue template
> <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository>.
> There are many others, though.
>

It seems that an issue template would put this information in a comment
where it's not filterable, and would need to be maintained.

There does seem to be an edit history but is there a label history? In Jira
basically any action on the issue is auditable. Imagine someone registers
an account and does something malicious (say someone who didn't like us
went and removed labels from a ton of issues? how would we know who, and
what labels to put back?). Hard to imagine perhaps, but the internet is
large and contains a large number of weirdos...


>
> Jira is very robust, but it is daunting. It seems that to make this
> proposal viable, a few members of the community need to commit to setting
> up and facilitating the transition. To me, it feels like a two month
> effort.
>
> Regarding .patch files, I think there are very few systems that still rely
> on them.
>

If we as a group decide to drop support for them, that's a possible
decision. It might need to precede the move to GitHub.


> , I despise how annoying Jira gets and think that more developers could
> get involved if we removed that dependency. GitHub actions give us lots of
> customizability.
>

Oh yes. Did you note my all caps words ;) I'm in no way suggesting that
Jira is particularly friendly to use. It's particularly frustrating that
half the things I listed look like they should be relatively easy to fix
and in one case they did it to themselves for no reason I can fathom.
Context and performance really being harder (context would take some
careful design so that the users who want to work across projects still
can, and really users like me would want a 2 project context...). I suspect
however that actions can't overcome the fact that Github doesn't store
distinct fields so unless we have some way of pulling data out of issue
comments and making it searchable, under separate fields, there will be
gaps.

It's been a long time since I've tried to look around in the issue tracker
space. Are there 3rd options that might be easier to use, under our direct
control and perhaps easier to influence. I've not looked at it, what do we
know about https://jackrabbit.apache.org/jcr/issue-tracker.html ? Would
have a nice ASF using it's own software angle...

Ok my quick search led me astray I somehow thought Jackrabbit was an
isuse tracker because I landed on that page first.. disregard that.

On Mon, May 9, 2022 at 10:19 AM Gus Heck <gus.heck@gmail.com> wrote:

> On the suggestion of private security only repo in another mail... that
> seems to mean security issues can never be made public? Presently we have a
> culture of openness where once the issue is resolved and a fix release we
> share the discussion. I think that's good since it can then lead security
> researchers or others to test our fix better and users can better
> understand why we had to remove something or whatever.
>
> responses inline
>
> On Sun, May 8, 2022 at 11:51 PM Marcus Eagan <marcuseagan@gmail.com>
> wrote:
>
>> Many of my opinions have been expressed, and of course my (non-binding)
>> vote for switching to GitHub issues is of little to no consequence.
>>
>>
> Binding votes are not the only important votes, as Tomoko pointed out.
>
>
>> I feel it would be wholly damaging to the Microsoft brand to pull the rug
>> under the many open source projects owned by non-profits and hosted
>> entirely on GitHub. Their leadership is trending toward the good and any
>> absurd actions like that would have very serious ramifications for their
>> business. I think it's a non-issue for the foreseeable future that is
>> outweighed by the benefits of shedding Jira. Furthermore, here's a short
>> list of tutorials
>> <https://gist.github.com/MarcusSorealheis/c3e5055442b89fdf0d32c392e95ea314> for
>> migrating back to Jira in a doomsday scenario.
>>
>
> I don't disagree, and I acknowledge that the recent trend is much
> improved, but It's a lever by which an external company motivated by profit
> can disrupt us if it happens to be in their interest. (besides profit,
> there could be political motives etc, Imagine prominent pmc members expose
> a flaw that really hurts them or sign some sort of open letter in favor of
> a political candidate that explicitly wants to target them with antitrust
> laws... not that happens anymore in the US but nevermind... ).
>
> I have a bias for the ASF and its projects to be self-sufficient
> where feasible, and while loss of donations would be an issue
> regardless, that would have to be at the ASF level and couldn't target
> specific projects or individuals making it far less attractive. One can
> argue that the irritations in Jira are making it infeasible, but that's my
> bias.
>
>
>>
>>> - No way to enforce that a resolution label is applied to the issue.
>>>
>>> We can enforce labels. It will require some customization to some of the
>> existing options. Here is a popular one
>> <https://github.com/marketplace/actions/require-labels>.
>>
>
> Hmm those are labels on PR's not issues. Github does not have an issue/pr
> direct linking
>
> Which reminds me I don't think there's a way to link issues such as "this
> one blocks that one" or "This one is related to that one", etc.
>
>
>>
>>
>>> - Document with each issue the Affected version and the fixed
>>> version.
>>>
>>> There are many ways to do this one. The simplest is the issue template
>> <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository>.
>> There are many others, though.
>>
>
> It seems that an issue template would put this information in a comment
> where it's not filterable, and would need to be maintained.
>
> There does seem to be an edit history but is there a label history? In
> Jira basically any action on the issue is auditable. Imagine someone
> registers an account and does something malicious (say someone who didn't
> like us went and removed labels from a ton of issues? how would we know
> who, and what labels to put back?). Hard to imagine perhaps, but the
> internet is large and contains a large number of weirdos...
>
>
>>
>> Jira is very robust, but it is daunting. It seems that to make this
>> proposal viable, a few members of the community need to commit to setting
>> up and facilitating the transition. To me, it feels like a two month
>> effort.
>>
>> Regarding .patch files, I think there are very few systems that still
>> rely on them.
>>
>
> If we as a group decide to drop support for them, that's a possible
> decision. It might need to precede the move to GitHub.
>
>
>> , I despise how annoying Jira gets and think that more developers could
>> get involved if we removed that dependency. GitHub actions give us lots of
>> customizability.
>>
>
> Oh yes. Did you note my all caps words ;) I'm in no way suggesting that
> Jira is particularly friendly to use. It's particularly frustrating that
> half the things I listed look like they should be relatively easy to fix
> and in one case they did it to themselves for no reason I can fathom.
> Context and performance really being harder (context would take some
> careful design so that the users who want to work across projects still
> can, and really users like me would want a 2 project context...). I suspect
> however that actions can't overcome the fact that Github doesn't store
> distinct fields so unless we have some way of pulling data out of issue
> comments and making it searchable, under separate fields, there will be
> gaps.
>
> It's been a long time since I've tried to look around in the issue tracker
> space. Are there 3rd options that might be easier to use, under our direct
> control and perhaps easier to influence. I've not looked at it, what do we
> know about https://jackrabbit.apache.org/jcr/issue-tracker.html ? Would
> have a nice ASF using it's own software angle...
>
>

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

I knew I had seen an apache issue tracker project...
https://bloodhound.apache.org/ which evidently descends from Trac, but it
appears to be more or less dead with no activity easily seen since 2014 :(

On Mon, May 9, 2022 at 10:27 AM Gus Heck <gus.heck@gmail.com> wrote:

> Ok my quick search led me astray I somehow thought Jackrabbit was an
> isuse tracker because I landed on that page first.. disregard that.
>
> On Mon, May 9, 2022 at 10:19 AM Gus Heck <gus.heck@gmail.com> wrote:
>
>> On the suggestion of private security only repo in another mail... that
>> seems to mean security issues can never be made public? Presently we have a
>> culture of openness where once the issue is resolved and a fix release we
>> share the discussion. I think that's good since it can then lead security
>> researchers or others to test our fix better and users can better
>> understand why we had to remove something or whatever.
>>
>> responses inline
>>
>> On Sun, May 8, 2022 at 11:51 PM Marcus Eagan <marcuseagan@gmail.com>
>> wrote:
>>
>>> Many of my opinions have been expressed, and of course my (non-binding)
>>> vote for switching to GitHub issues is of little to no consequence.
>>>
>>>
>> Binding votes are not the only important votes, as Tomoko pointed out.
>>
>>
>>> I feel it would be wholly damaging to the Microsoft brand to pull the
>>> rug under the many open source projects owned by non-profits and hosted
>>> entirely on GitHub. Their leadership is trending toward the good and any
>>> absurd actions like that would have very serious ramifications for their
>>> business. I think it's a non-issue for the foreseeable future that is
>>> outweighed by the benefits of shedding Jira. Furthermore, here's a short
>>> list of tutorials
>>> <https://gist.github.com/MarcusSorealheis/c3e5055442b89fdf0d32c392e95ea314> for
>>> migrating back to Jira in a doomsday scenario.
>>>
>>
>> I don't disagree, and I acknowledge that the recent trend is much
>> improved, but It's a lever by which an external company motivated by profit
>> can disrupt us if it happens to be in their interest. (besides profit,
>> there could be political motives etc, Imagine prominent pmc members expose
>> a flaw that really hurts them or sign some sort of open letter in favor of
>> a political candidate that explicitly wants to target them with antitrust
>> laws... not that happens anymore in the US but nevermind... ).
>>
>> I have a bias for the ASF and its projects to be self-sufficient
>> where feasible, and while loss of donations would be an issue
>> regardless, that would have to be at the ASF level and couldn't target
>> specific projects or individuals making it far less attractive. One can
>> argue that the irritations in Jira are making it infeasible, but that's my
>> bias.
>>
>>
>>>
>>>> - No way to enforce that a resolution label is applied to the issue.
>>>>
>>>> We can enforce labels. It will require some customization to some of
>>> the existing options. Here is a popular one
>>> <https://github.com/marketplace/actions/require-labels>.
>>>
>>
>> Hmm those are labels on PR's not issues. Github does not have an issue/pr
>> direct linking
>>
>> Which reminds me I don't think there's a way to link issues such as "this
>> one blocks that one" or "This one is related to that one", etc.
>>
>>
>>>
>>>
>>>> - Document with each issue the Affected version and the fixed
>>>> version.
>>>>
>>>> There are many ways to do this one. The simplest is the issue template
>>> <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository>.
>>> There are many others, though.
>>>
>>
>> It seems that an issue template would put this information in a comment
>> where it's not filterable, and would need to be maintained.
>>
>> There does seem to be an edit history but is there a label history? In
>> Jira basically any action on the issue is auditable. Imagine someone
>> registers an account and does something malicious (say someone who didn't
>> like us went and removed labels from a ton of issues? how would we know
>> who, and what labels to put back?). Hard to imagine perhaps, but the
>> internet is large and contains a large number of weirdos...
>>
>>
>>>
>>> Jira is very robust, but it is daunting. It seems that to make this
>>> proposal viable, a few members of the community need to commit to setting
>>> up and facilitating the transition. To me, it feels like a two month
>>> effort.
>>>
>>> Regarding .patch files, I think there are very few systems that still
>>> rely on them.
>>>
>>
>> If we as a group decide to drop support for them, that's a possible
>> decision. It might need to precede the move to GitHub.
>>
>>
>>> , I despise how annoying Jira gets and think that more developers could
>>> get involved if we removed that dependency. GitHub actions give us lots of
>>> customizability.
>>>
>>
>> Oh yes. Did you note my all caps words ;) I'm in no way suggesting that
>> Jira is particularly friendly to use. It's particularly frustrating that
>> half the things I listed look like they should be relatively easy to fix
>> and in one case they did it to themselves for no reason I can fathom.
>> Context and performance really being harder (context would take some
>> careful design so that the users who want to work across projects still
>> can, and really users like me would want a 2 project context...). I suspect
>> however that actions can't overcome the fact that Github doesn't store
>> distinct fields so unless we have some way of pulling data out of issue
>> comments and making it searchable, under separate fields, there will be
>> gaps.
>>
>> It's been a long time since I've tried to look around in the issue
>> tracker space. Are there 3rd options that might be easier to use, under our
>> direct control and perhaps easier to influence. I've not looked at it, what
>> do we know about https://jackrabbit.apache.org/jcr/issue-tracker.html ?
>> Would have a nice ASF using it's own software angle...
>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>


--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

On Mon, 9 May 2022, Gus Heck wrote:

> It's been a long time since I've tried to look around in the issue tracker
> space. Are there 3rd options that might be easier to use, under our direct
> control and perhaps easier to influence. I've not looked at it, what do we
> know about https://jackrabbit.apache.org/jcr/issue-tracker.html ? Would
> have a nice ASF using it's own software angle...

As I suggested earlier, an Apache hosted version of GitLab might work. I'm
not sure how different it is from GitHub from the point of view of issue
tracking but it checks the better control box. The ASF has been hosting all
our infra for decades, I'm sure they're capable of hosting a GitLab install.
If the Videolan [1] (VLC project) or the ISC [2] (Bind project) can do it,
so can Apache.

Andi..

[1] https://code.videolan.org/videolan/vlc
[2] https://gitlab.isc.org/isc-projects/bind9


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Thanks all for your various suggestions.
I'm sorry for cutting into the conversation but let's focus on the simple
binary decision on "migration to GitHub issue is better or not for us" here.

My proposal is about nothing but the transition to GitHub issue from Jira;
introducing other new tools like GitLab, or something else is another
discussion.

Tomoko


2022?5?10?(?) 1:23 Andi Vajda <osaf@ovaltofu.org>:

>
> On Mon, 9 May 2022, Gus Heck wrote:
>
> > It's been a long time since I've tried to look around in the issue
> tracker
> > space. Are there 3rd options that might be easier to use, under our
> direct
> > control and perhaps easier to influence. I've not looked at it, what do
> we
> > know about https://jackrabbit.apache.org/jcr/issue-tracker.html ? Would
> > have a nice ASF using it's own software angle...
>
> As I suggested earlier, an Apache hosted version of GitLab might work. I'm
> not sure how different it is from GitHub from the point of view of issue
> tracking but it checks the better control box. The ASF has been hosting
> all
> our infra for decades, I'm sure they're capable of hosting a GitLab
> install.
> If the Videolan [1] (VLC project) or the ISC [2] (Bind project) can do it,
> so can Apache.
>
> Andi..
>
> [1] https://code.videolan.org/videolan/vlc
> [2] https://gitlab.isc.org/isc-projects/bind9
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Also, I have a great deal to be concerned about "what active
committers/contributors on Lucene actually think of it".

I won't intend to insist you all express your thoughts until the official
vote - if this discussion is successfully turned to it, but this could
drastically change your daily activities/experiences.
If developers who use both GitHub and Jira on a daily basis don't take the
proposal as useful, the discussion is almost meaningless to me.

Repeating myself, my first motivation here is to improve the experiences of
active contributors.

Thank you,
Tomoko


2022?5?10?(?) 5:21 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:

> Thanks all for your various suggestions.
> I'm sorry for cutting into the conversation but let's focus on the simple
> binary decision on "migration to GitHub issue is better or not for us" here.
>
> My proposal is about nothing but the transition to GitHub issue from Jira;
> introducing other new tools like GitLab, or something else is another
> discussion.
>
> Tomoko
>
>
> 2022?5?10?(?) 1:23 Andi Vajda <osaf@ovaltofu.org>:
>
>>
>> On Mon, 9 May 2022, Gus Heck wrote:
>>
>> > It's been a long time since I've tried to look around in the issue
>> tracker
>> > space. Are there 3rd options that might be easier to use, under our
>> direct
>> > control and perhaps easier to influence. I've not looked at it, what do
>> we
>> > know about https://jackrabbit.apache.org/jcr/issue-tracker.html ? Would
>> > have a nice ASF using it's own software angle...
>>
>> As I suggested earlier, an Apache hosted version of GitLab might work.
>> I'm
>> not sure how different it is from GitHub from the point of view of issue
>> tracking but it checks the better control box. The ASF has been hosting
>> all
>> our infra for decades, I'm sure they're capable of hosting a GitLab
>> install.
>> If the Videolan [1] (VLC project) or the ISC [2] (Bind project) can do
>> it,
>> so can Apache.
>>
>> Andi..
>>
>> [1] https://code.videolan.org/videolan/vlc
>> [2] https://gitlab.isc.org/isc-projects/bind9
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> Also, I have a great deal to be concerned about "what active committers/contributors on Lucene actually think of it".
>

I have a couple thoughts.

1. What percentage of contributions are done via pull requests versus
via patch files these days? I'm always happy to commit a patch, but I
just don't see them. I'm still happy to commit a patch sent to the
mailing list. I feel that requiring JIRA is just unnecessarily
invoking another tool, another signup process, unnecessary hurdle. If
someone wants to send a patch to the mailing list, e.g. from the user
list as part of a discussion, that's fine.
2. Realistically, every committer actively merging/committing is using
github today already. This proposal doesn't make their life any more
difficult. They already have their github account setup. It makes life
easier for the *contributor*, which is what I want.
3. Around concerns of github "censorship" and certain countries, this
doesn't affect public repositories, just private ones. It has to do
with sanctions and money and so on. I see you committed Persian
Stemmer from an Iranian contributor just this morning. This is not a
problem.
4. Still along these lines, I tested this stuff from behind chinese
great firewall this morning, to have the full experience myself.
lucene.apache.org site is extremely fast, fastly CDN! github.com was a
bit slower to load, but not terrible. Loading up JIRA
(issues.apache.org) was very slow, required both getting and drinking
another coffee. It is some machine out there in hetzner germany, which
may be the issue. At the same time, I think it is unreasonable to ask
infra to "cluster" the JIRA for better access around the world,
because that's absurdly scary from a technical perspective. So I'm
happy if we can streamline the contribution process and make it easier
for folks outside of US and europe.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Thank you Robert for your feedback.

I'm also sorry if my previous mail was urging explicit feedback - I
understand such a request goes against the "lazy consensus" practice in
Apache.
I'd be grateful to hear thoughts or simply +1 / -1 / +-0 from developers
who are actually affected by this proposal if you are interested.

Thanks,
Tomoko


2022?5?10?(?) 9:36 Robert Muir <rcmuir@gmail.com>:

> On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida
> <tomoko.uchida.1111@gmail.com> wrote:
> >
> > Also, I have a great deal to be concerned about "what active
> committers/contributors on Lucene actually think of it".
> >
>
> I have a couple thoughts.
>
> 1. What percentage of contributions are done via pull requests versus
> via patch files these days? I'm always happy to commit a patch, but I
> just don't see them. I'm still happy to commit a patch sent to the
> mailing list. I feel that requiring JIRA is just unnecessarily
> invoking another tool, another signup process, unnecessary hurdle. If
> someone wants to send a patch to the mailing list, e.g. from the user
> list as part of a discussion, that's fine.
> 2. Realistically, every committer actively merging/committing is using
> github today already. This proposal doesn't make their life any more
> difficult. They already have their github account setup. It makes life
> easier for the *contributor*, which is what I want.
> 3. Around concerns of github "censorship" and certain countries, this
> doesn't affect public repositories, just private ones. It has to do
> with sanctions and money and so on. I see you committed Persian
> Stemmer from an Iranian contributor just this morning. This is not a
> problem.
> 4. Still along these lines, I tested this stuff from behind chinese
> great firewall this morning, to have the full experience myself.
> lucene.apache.org site is extremely fast, fastly CDN! github.com was a
> bit slower to load, but not terrible. Loading up JIRA
> (issues.apache.org) was very slow, required both getting and drinking
> another coffee. It is some machine out there in hetzner germany, which
> may be the issue. At the same time, I think it is unreasonable to ask
> infra to "cluster" the JIRA for better access around the world,
> because that's absurdly scary from a technical perspective. So I'm
> happy if we can streamline the contribution process and make it easier
> for folks outside of US and europe.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

I'll keep open this thread for a while - while almost all concern for the
transition seems to be already on the table, I feel we'd need more
participation from committers who actively work for this project. Without
mature discussion among active committers and contributors, the vote would
not yield a good result whether it is passed or not.

I don't want to disturb the coming release so I'm not going to move this
until the 9.2 release is done; but please feel free to leave comments.

Tomoko


2022?5?10?(?) 11:06 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:

> Thank you Robert for your feedback.
>
> I'm also sorry if my previous mail was urging explicit feedback - I
> understand such a request goes against the "lazy consensus" practice in
> Apache.
> I'd be grateful to hear thoughts or simply +1 / -1 / +-0 from developers
> who are actually affected by this proposal if you are interested.
>
> Thanks,
> Tomoko
>
>
> 2022?5?10?(?) 9:36 Robert Muir <rcmuir@gmail.com>:
>
>> On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida
>> <tomoko.uchida.1111@gmail.com> wrote:
>> >
>> > Also, I have a great deal to be concerned about "what active
>> committers/contributors on Lucene actually think of it".
>> >
>>
>> I have a couple thoughts.
>>
>> 1. What percentage of contributions are done via pull requests versus
>> via patch files these days? I'm always happy to commit a patch, but I
>> just don't see them. I'm still happy to commit a patch sent to the
>> mailing list. I feel that requiring JIRA is just unnecessarily
>> invoking another tool, another signup process, unnecessary hurdle. If
>> someone wants to send a patch to the mailing list, e.g. from the user
>> list as part of a discussion, that's fine.
>> 2. Realistically, every committer actively merging/committing is using
>> github today already. This proposal doesn't make their life any more
>> difficult. They already have their github account setup. It makes life
>> easier for the *contributor*, which is what I want.
>> 3. Around concerns of github "censorship" and certain countries, this
>> doesn't affect public repositories, just private ones. It has to do
>> with sanctions and money and so on. I see you committed Persian
>> Stemmer from an Iranian contributor just this morning. This is not a
>> problem.
>> 4. Still along these lines, I tested this stuff from behind chinese
>> great firewall this morning, to have the full experience myself.
>> lucene.apache.org site is extremely fast, fastly CDN! github.com was a
>> bit slower to load, but not terrible. Loading up JIRA
>> (issues.apache.org) was very slow, required both getting and drinking
>> another coffee. It is some machine out there in hetzner germany, which
>> may be the issue. At the same time, I think it is unreasonable to ask
>> infra to "cluster" the JIRA for better access around the world,
>> because that's absurdly scary from a technical perspective. So I'm
>> happy if we can streamline the contribution process and make it easier
>> for folks outside of US and europe.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

Hi Tomoko,
thanks for raising this!

I am always in favor of simplicity and with the idea that code should speak
for itself(readable code and meaningful commit messages over dirty code
covered by a detailed Jira issue).

Now, given that, I have been using Jira for many years, I agree with all
the limitations mentioned so far but I am generally happy about using it.
I have limited experience with the Github issue system, it looks definitely
"simpler" than Jira, not sure it covers all our requirements.

Being a bit provocative and thinking out loud, I see a true necessity of
raising issues(Jira or Github) in these instances:
1) proposal that needs discussion and doesn't have a clear solution
2) raise a bug/task/story we are not planning to do ourselves immediately
(so we want to give the community the chance of doing it while we are busy)
3) planning, using sprints etc (we don't do)

Whenever we have a contribution or bugfix ready (as an output of our daily
working activity), it feels to me that it's unnecessary to create an issue
at all, modern pull requests are perfectly fine for adding all the
necessary details, tag people for review or discuss the contribution: to me
having to open any kind of issue is just an unnecessary boilerplate
activity (and duplication of description, comments, etc).
Pretty sure I am missing something, but I just wanted to give a quick
glance of a recent feeling of mine.

Long story short, if the Github issue system covers all our requirements, I
think it's going to be beneficial to keep all in the "same" place and would
ease contributions.
But I am arguing we should not open an issue for each contribution, most of
the time the Pull Request should be enough.
Of course, we should estimate the effort, identify people that
realistically want to work for that and then vote if the amount of
dedication is worth.

In regards to nationality bans, and sanctions etc, I am personally not that
worried, aren't we relying quite strongly already on Github for the repos,
pull requests, etc?(and I assume many other infrastructures potentially
owned by organizations that could impose certain bans?)
Ideally, we want to just use tools owned by the Apache Software Foundation,
but realistically sometimes you need to compromise.
I would suggest we organize a voting session to see how strong the banning
concern is, across the committers community, because generally, I think
it's a fair point.

Finally, I would like to raise a question:
does anybody know if it's possible to create automatically "CHANGES" on
GitHub, based on pull requests and merges maybe(or issues)?
We were discussing removing the necessity of the (pretty annoying and
error-prone) "CHANGES.txt", and wondering if Jira could automatically solve
that necessity.
If GitHub is better at that, could be a strong incentive to go in that
direction!

Cheers



--------------------------
*Alessandro Benedetti*
CEO @ Sease Ltd.
*Apache Lucene/Solr Committer*
*Apache Solr PMC Member*

e-mail: a.benedetti@sease.io


*Sease* - Information Retrieval Applied
Consulting | Training | Open Source

Website: Sease.io <http://sease.io/>
LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter
<https://twitter.com/seaseltd> | Youtube
<https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github
<https://github.com/seaseltd>


On Tue, 10 May 2022 at 06:04, Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> I'll keep open this thread for a while - while almost all concern for the
> transition seems to be already on the table, I feel we'd need more
> participation from committers who actively work for this project. Without
> mature discussion among active committers and contributors, the vote would
> not yield a good result whether it is passed or not.
>
> I don't want to disturb the coming release so I'm not going to move this
> until the 9.2 release is done; but please feel free to leave comments.
>
> Tomoko
>
>
> 2022?5?10?(?) 11:06 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>
>> Thank you Robert for your feedback.
>>
>> I'm also sorry if my previous mail was urging explicit feedback - I
>> understand such a request goes against the "lazy consensus" practice in
>> Apache.
>> I'd be grateful to hear thoughts or simply +1 / -1 / +-0 from developers
>> who are actually affected by this proposal if you are interested.
>>
>> Thanks,
>> Tomoko
>>
>>
>> 2022?5?10?(?) 9:36 Robert Muir <rcmuir@gmail.com>:
>>
>>> On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida
>>> <tomoko.uchida.1111@gmail.com> wrote:
>>> >
>>> > Also, I have a great deal to be concerned about "what active
>>> committers/contributors on Lucene actually think of it".
>>> >
>>>
>>> I have a couple thoughts.
>>>
>>> 1. What percentage of contributions are done via pull requests versus
>>> via patch files these days? I'm always happy to commit a patch, but I
>>> just don't see them. I'm still happy to commit a patch sent to the
>>> mailing list. I feel that requiring JIRA is just unnecessarily
>>> invoking another tool, another signup process, unnecessary hurdle. If
>>> someone wants to send a patch to the mailing list, e.g. from the user
>>> list as part of a discussion, that's fine.
>>> 2. Realistically, every committer actively merging/committing is using
>>> github today already. This proposal doesn't make their life any more
>>> difficult. They already have their github account setup. It makes life
>>> easier for the *contributor*, which is what I want.
>>> 3. Around concerns of github "censorship" and certain countries, this
>>> doesn't affect public repositories, just private ones. It has to do
>>> with sanctions and money and so on. I see you committed Persian
>>> Stemmer from an Iranian contributor just this morning. This is not a
>>> problem.
>>> 4. Still along these lines, I tested this stuff from behind chinese
>>> great firewall this morning, to have the full experience myself.
>>> lucene.apache.org site is extremely fast, fastly CDN! github.com was a
>>> bit slower to load, but not terrible. Loading up JIRA
>>> (issues.apache.org) was very slow, required both getting and drinking
>>> another coffee. It is some machine out there in hetzner germany, which
>>> may be the issue. At the same time, I think it is unreasonable to ask
>>> infra to "cluster" the JIRA for better access around the world,
>>> because that's absurdly scary from a technical perspective. So I'm
>>> happy if we can streamline the contribution process and make it easier
>>> for folks outside of US and europe.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>

Thanks Alessandro for openly sharing your perspective!

> I have limited experience with the Github issue system, it looks
definitely "simpler" than Jira, not sure it covers all our requirements.

I feel I'd need to explain my thoughts on this point. Yes, I think I know
very well about such kind of discussion - "We're using XXX for YYY, does
the new shiny ZZZ tool work as its replacement? Does ZZZ satisfy our
use-cases so far?"
But - I don't want to make this discuss thread into a feature comparison of
Jira vs GitHub.
It's not about features, but about accepting a new framework to me. GitHub
issue would not be a replacement Jira, and we cannot operate this project
on GitHub issue in the same way on Jira. We'd need to build our new
convention and operations on the new toolkit. I myself am optimistic about
we can do it well if we fully decide to accept the worldview the tool
provides for us.

If many of you (here I mean, committers) feel "It's okay if our current
operation will be kept on GitHub.", I won't be able to fulfill your
expecttations.
It's my position - and if it's not acceptable, I'd be happy to fail this
proposal.

Thanks,
Tomoko


2022?5?10?(?) 18:41 Alessandro Benedetti <a.benedetti@sease.io>:

> Hi Tomoko,
> thanks for raising this!
>
> I am always in favor of simplicity and with the idea that code should
> speak for itself(readable code and meaningful commit messages over dirty
> code covered by a detailed Jira issue).
>
> Now, given that, I have been using Jira for many years, I agree with all
> the limitations mentioned so far but I am generally happy about using it.
> I have limited experience with the Github issue system, it looks
> definitely "simpler" than Jira, not sure it covers all our requirements.
>
> Being a bit provocative and thinking out loud, I see a true necessity of
> raising issues(Jira or Github) in these instances:
> 1) proposal that needs discussion and doesn't have a clear solution
> 2) raise a bug/task/story we are not planning to do ourselves immediately
> (so we want to give the community the chance of doing it while we are busy)
> 3) planning, using sprints etc (we don't do)
>
> Whenever we have a contribution or bugfix ready (as an output of our daily
> working activity), it feels to me that it's unnecessary to create an issue
> at all, modern pull requests are perfectly fine for adding all the
> necessary details, tag people for review or discuss the contribution: to me
> having to open any kind of issue is just an unnecessary boilerplate
> activity (and duplication of description, comments, etc).
> Pretty sure I am missing something, but I just wanted to give a quick
> glance of a recent feeling of mine.
>
> Long story short, if the Github issue system covers all our requirements,
> I think it's going to be beneficial to keep all in the "same" place and
> would ease contributions.
> But I am arguing we should not open an issue for each contribution, most
> of the time the Pull Request should be enough.
> Of course, we should estimate the effort, identify people that
> realistically want to work for that and then vote if the amount of
> dedication is worth.
>
> In regards to nationality bans, and sanctions etc, I am personally not
> that worried, aren't we relying quite strongly already on Github for the
> repos, pull requests, etc?(and I assume many other infrastructures
> potentially owned by organizations that could impose certain bans?)
> Ideally, we want to just use tools owned by the Apache Software
> Foundation, but realistically sometimes you need to compromise.
> I would suggest we organize a voting session to see how strong the banning
> concern is, across the committers community, because generally, I think
> it's a fair point.
>
> Finally, I would like to raise a question:
> does anybody know if it's possible to create automatically "CHANGES" on
> GitHub, based on pull requests and merges maybe(or issues)?
> We were discussing removing the necessity of the (pretty annoying and
> error-prone) "CHANGES.txt", and wondering if Jira could automatically solve
> that necessity.
> If GitHub is better at that, could be a strong incentive to go in that
> direction!
>
> Cheers
>
>
>
> --------------------------
> *Alessandro Benedetti*
> CEO @ Sease Ltd.
> *Apache Lucene/Solr Committer*
> *Apache Solr PMC Member*
>
> e-mail: a.benedetti@sease.io
>
>
> *Sease* - Information Retrieval Applied
> Consulting | Training | Open Source
>
> Website: Sease.io <http://sease.io/>
> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter
> <https://twitter.com/seaseltd> | Youtube
> <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github
> <https://github.com/seaseltd>
>
>
> On Tue, 10 May 2022 at 06:04, Tomoko Uchida <tomoko.uchida.1111@gmail.com>
> wrote:
>
>> I'll keep open this thread for a while - while almost all concern for the
>> transition seems to be already on the table, I feel we'd need more
>> participation from committers who actively work for this project. Without
>> mature discussion among active committers and contributors, the vote would
>> not yield a good result whether it is passed or not.
>>
>> I don't want to disturb the coming release so I'm not going to move this
>> until the 9.2 release is done; but please feel free to leave comments.
>>
>> Tomoko
>>
>>
>> 2022?5?10?(?) 11:06 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>
>>> Thank you Robert for your feedback.
>>>
>>> I'm also sorry if my previous mail was urging explicit feedback - I
>>> understand such a request goes against the "lazy consensus" practice in
>>> Apache.
>>> I'd be grateful to hear thoughts or simply +1 / -1 / +-0 from developers
>>> who are actually affected by this proposal if you are interested.
>>>
>>> Thanks,
>>> Tomoko
>>>
>>>
>>> 2022?5?10?(?) 9:36 Robert Muir <rcmuir@gmail.com>:
>>>
>>>> On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida
>>>> <tomoko.uchida.1111@gmail.com> wrote:
>>>> >
>>>> > Also, I have a great deal to be concerned about "what active
>>>> committers/contributors on Lucene actually think of it".
>>>> >
>>>>
>>>> I have a couple thoughts.
>>>>
>>>> 1. What percentage of contributions are done via pull requests versus
>>>> via patch files these days? I'm always happy to commit a patch, but I
>>>> just don't see them. I'm still happy to commit a patch sent to the
>>>> mailing list. I feel that requiring JIRA is just unnecessarily
>>>> invoking another tool, another signup process, unnecessary hurdle. If
>>>> someone wants to send a patch to the mailing list, e.g. from the user
>>>> list as part of a discussion, that's fine.
>>>> 2. Realistically, every committer actively merging/committing is using
>>>> github today already. This proposal doesn't make their life any more
>>>> difficult. They already have their github account setup. It makes life
>>>> easier for the *contributor*, which is what I want.
>>>> 3. Around concerns of github "censorship" and certain countries, this
>>>> doesn't affect public repositories, just private ones. It has to do
>>>> with sanctions and money and so on. I see you committed Persian
>>>> Stemmer from an Iranian contributor just this morning. This is not a
>>>> problem.
>>>> 4. Still along these lines, I tested this stuff from behind chinese
>>>> great firewall this morning, to have the full experience myself.
>>>> lucene.apache.org site is extremely fast, fastly CDN! github.com was a
>>>> bit slower to load, but not terrible. Loading up JIRA
>>>> (issues.apache.org) was very slow, required both getting and drinking
>>>> another coffee. It is some machine out there in hetzner germany, which
>>>> may be the issue. At the same time, I think it is unreasonable to ask
>>>> infra to "cluster" the JIRA for better access around the world,
>>>> because that's absurdly scary from a technical perspective. So I'm
>>>> happy if we can streamline the contribution process and make it easier
>>>> for folks outside of US and europe.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>

>
> It's not about features, but about accepting a new framework to me. GitHub
> issue would not be a replacement Jira, and we cannot operate this project
> on GitHub issue in the same way on Jira. We'd need to build our new
> convention and operations on the new toolkit.
>

I think this is a very important point. We have done a good job of using
Github Issues 100% for the Solr Operator, but that is definitely smaller
than Lucene and Solr. I think it's doable but we will definitely have to
build in processes (like other large projects have done). Github Issues is
not as powerful as JIRA, but maybe in the long-term that will be a good
thing? Also Github has been improving over the last few years, and I have
only seen JIRA either stay the same or get worse in the ~decade I've been
working on the project.

Most modern open source projects use Github Issues for their issue
tracking, so it's definitely doable, and really what new
users/contributors will be expecting. Also I see that much discussion is
already done on PRs, and JIRAs are mainly there just for
bureaucratic purposes. So I think it would be a wonderful direction to go
in.

- Houston

On Tue, May 10, 2022 at 8:06 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> Thanks Alessandro for openly sharing your perspective!
>
> > I have limited experience with the Github issue system, it looks
> definitely "simpler" than Jira, not sure it covers all our requirements.
>
> I feel I'd need to explain my thoughts on this point. Yes, I think I know
> very well about such kind of discussion - "We're using XXX for YYY, does
> the new shiny ZZZ tool work as its replacement? Does ZZZ satisfy our
> use-cases so far?"
> But - I don't want to make this discuss thread into a feature comparison
> of Jira vs GitHub.
> It's not about features, but about accepting a new framework to me. GitHub
> issue would not be a replacement Jira, and we cannot operate this project
> on GitHub issue in the same way on Jira. We'd need to build our new
> convention and operations on the new toolkit. I myself am optimistic about
> we can do it well if we fully decide to accept the worldview the tool
> provides for us.
>
> If many of you (here I mean, committers) feel "It's okay if our current
> operation will be kept on GitHub.", I won't be able to fulfill your
> expecttations.
> It's my position - and if it's not acceptable, I'd be happy to fail this
> proposal.
>
> Thanks,
> Tomoko
>
>
> 2022?5?10?(?) 18:41 Alessandro Benedetti <a.benedetti@sease.io>:
>
>> Hi Tomoko,
>> thanks for raising this!
>>
>> I am always in favor of simplicity and with the idea that code should
>> speak for itself(readable code and meaningful commit messages over dirty
>> code covered by a detailed Jira issue).
>>
>> Now, given that, I have been using Jira for many years, I agree with all
>> the limitations mentioned so far but I am generally happy about using it.
>> I have limited experience with the Github issue system, it looks
>> definitely "simpler" than Jira, not sure it covers all our requirements.
>>
>> Being a bit provocative and thinking out loud, I see a true necessity of
>> raising issues(Jira or Github) in these instances:
>> 1) proposal that needs discussion and doesn't have a clear solution
>> 2) raise a bug/task/story we are not planning to do ourselves immediately
>> (so we want to give the community the chance of doing it while we are busy)
>> 3) planning, using sprints etc (we don't do)
>>
>> Whenever we have a contribution or bugfix ready (as an output of our
>> daily working activity), it feels to me that it's unnecessary to create an
>> issue at all, modern pull requests are perfectly fine for adding all the
>> necessary details, tag people for review or discuss the contribution: to me
>> having to open any kind of issue is just an unnecessary boilerplate
>> activity (and duplication of description, comments, etc).
>> Pretty sure I am missing something, but I just wanted to give a quick
>> glance of a recent feeling of mine.
>>
>> Long story short, if the Github issue system covers all our requirements,
>> I think it's going to be beneficial to keep all in the "same" place and
>> would ease contributions.
>> But I am arguing we should not open an issue for each contribution, most
>> of the time the Pull Request should be enough.
>> Of course, we should estimate the effort, identify people that
>> realistically want to work for that and then vote if the amount of
>> dedication is worth.
>>
>> In regards to nationality bans, and sanctions etc, I am personally not
>> that worried, aren't we relying quite strongly already on Github for the
>> repos, pull requests, etc?(and I assume many other infrastructures
>> potentially owned by organizations that could impose certain bans?)
>> Ideally, we want to just use tools owned by the Apache Software
>> Foundation, but realistically sometimes you need to compromise.
>> I would suggest we organize a voting session to see how strong the
>> banning concern is, across the committers community, because generally, I
>> think it's a fair point.
>>
>> Finally, I would like to raise a question:
>> does anybody know if it's possible to create automatically "CHANGES" on
>> GitHub, based on pull requests and merges maybe(or issues)?
>> We were discussing removing the necessity of the (pretty annoying and
>> error-prone) "CHANGES.txt", and wondering if Jira could automatically solve
>> that necessity.
>> If GitHub is better at that, could be a strong incentive to go in that
>> direction!
>>
>> Cheers
>>
>>
>>
>> --------------------------
>> *Alessandro Benedetti*
>> CEO @ Sease Ltd.
>> *Apache Lucene/Solr Committer*
>> *Apache Solr PMC Member*
>>
>> e-mail: a.benedetti@sease.io
>>
>>
>> *Sease* - Information Retrieval Applied
>> Consulting | Training | Open Source
>>
>> Website: Sease.io <http://sease.io/>
>> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter
>> <https://twitter.com/seaseltd> | Youtube
>> <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github
>> <https://github.com/seaseltd>
>>
>>
>> On Tue, 10 May 2022 at 06:04, Tomoko Uchida <tomoko.uchida.1111@gmail.com>
>> wrote:
>>
>>> I'll keep open this thread for a while - while almost all concern for
>>> the transition seems to be already on the table, I feel we'd need more
>>> participation from committers who actively work for this project. Without
>>> mature discussion among active committers and contributors, the vote would
>>> not yield a good result whether it is passed or not.
>>>
>>> I don't want to disturb the coming release so I'm not going to move this
>>> until the 9.2 release is done; but please feel free to leave comments.
>>>
>>> Tomoko
>>>
>>>
>>> 2022?5?10?(?) 11:06 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>>
>>>> Thank you Robert for your feedback.
>>>>
>>>> I'm also sorry if my previous mail was urging explicit feedback - I
>>>> understand such a request goes against the "lazy consensus" practice in
>>>> Apache.
>>>> I'd be grateful to hear thoughts or simply +1 / -1 / +-0 from
>>>> developers who are actually affected by this proposal if you are interested.
>>>>
>>>> Thanks,
>>>> Tomoko
>>>>
>>>>
>>>> 2022?5?10?(?) 9:36 Robert Muir <rcmuir@gmail.com>:
>>>>
>>>>> On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida
>>>>> <tomoko.uchida.1111@gmail.com> wrote:
>>>>> >
>>>>> > Also, I have a great deal to be concerned about "what active
>>>>> committers/contributors on Lucene actually think of it".
>>>>> >
>>>>>
>>>>> I have a couple thoughts.
>>>>>
>>>>> 1. What percentage of contributions are done via pull requests versus
>>>>> via patch files these days? I'm always happy to commit a patch, but I
>>>>> just don't see them. I'm still happy to commit a patch sent to the
>>>>> mailing list. I feel that requiring JIRA is just unnecessarily
>>>>> invoking another tool, another signup process, unnecessary hurdle. If
>>>>> someone wants to send a patch to the mailing list, e.g. from the user
>>>>> list as part of a discussion, that's fine.
>>>>> 2. Realistically, every committer actively merging/committing is using
>>>>> github today already. This proposal doesn't make their life any more
>>>>> difficult. They already have their github account setup. It makes life
>>>>> easier for the *contributor*, which is what I want.
>>>>> 3. Around concerns of github "censorship" and certain countries, this
>>>>> doesn't affect public repositories, just private ones. It has to do
>>>>> with sanctions and money and so on. I see you committed Persian
>>>>> Stemmer from an Iranian contributor just this morning. This is not a
>>>>> problem.
>>>>> 4. Still along these lines, I tested this stuff from behind chinese
>>>>> great firewall this morning, to have the full experience myself.
>>>>> lucene.apache.org site is extremely fast, fastly CDN! github.com was a
>>>>> bit slower to load, but not terrible. Loading up JIRA
>>>>> (issues.apache.org) was very slow, required both getting and drinking
>>>>> another coffee. It is some machine out there in hetzner germany, which
>>>>> may be the issue. At the same time, I think it is unreasonable to ask
>>>>> infra to "cluster" the JIRA for better access around the world,
>>>>> because that's absurdly scary from a technical perspective. So I'm
>>>>> happy if we can streamline the contribution process and make it easier
>>>>> for folks outside of US and europe.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>

Yes, the listing of differences (that we rely on) of course has two
resolution paths to facilitate such a move. A) find a way to fill the gap
B) decide we don't care about the gap - either is fine so long as it's an
intentional decision, not an oops we discover and regret later.

On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org> wrote:

> It's not about features, but about accepting a new framework to me. GitHub
>> issue would not be a replacement Jira, and we cannot operate this project
>> on GitHub issue in the same way on Jira. We'd need to build our new
>> convention and operations on the new toolkit.
>>
>
> I think this is a very important point. We have done a good job of using
> Github Issues 100% for the Solr Operator, but that is definitely smaller
> than Lucene and Solr. I think it's doable but we will definitely have to
> build in processes (like other large projects have done). Github Issues is
> not as powerful as JIRA, but maybe in the long-term that will be a good
> thing? Also Github has been improving over the last few years, and I have
> only seen JIRA either stay the same or get worse in the ~decade I've been
> working on the project.
>
> Most modern open source projects use Github Issues for their issue
> tracking, so it's definitely doable, and really what new
> users/contributors will be expecting. Also I see that much discussion is
> already done on PRs, and JIRAs are mainly there just for
> bureaucratic purposes. So I think it would be a wonderful direction to go
> in.
>
> - Houston
>
> On Tue, May 10, 2022 at 8:06 AM Tomoko Uchida <
> tomoko.uchida.1111@gmail.com> wrote:
>
>> Thanks Alessandro for openly sharing your perspective!
>>
>> > I have limited experience with the Github issue system, it looks
>> definitely "simpler" than Jira, not sure it covers all our requirements.
>>
>> I feel I'd need to explain my thoughts on this point. Yes, I think I know
>> very well about such kind of discussion - "We're using XXX for YYY, does
>> the new shiny ZZZ tool work as its replacement? Does ZZZ satisfy our
>> use-cases so far?"
>> But - I don't want to make this discuss thread into a feature comparison
>> of Jira vs GitHub.
>> It's not about features, but about accepting a new framework to me.
>> GitHub issue would not be a replacement Jira, and we cannot operate this
>> project on GitHub issue in the same way on Jira. We'd need to build our new
>> convention and operations on the new toolkit. I myself am optimistic about
>> we can do it well if we fully decide to accept the worldview the tool
>> provides for us.
>>
>> If many of you (here I mean, committers) feel "It's okay if our current
>> operation will be kept on GitHub.", I won't be able to fulfill your
>> expecttations.
>> It's my position - and if it's not acceptable, I'd be happy to fail this
>> proposal.
>>
>> Thanks,
>> Tomoko
>>
>>
>> 2022?5?10?(?) 18:41 Alessandro Benedetti <a.benedetti@sease.io>:
>>
>>> Hi Tomoko,
>>> thanks for raising this!
>>>
>>> I am always in favor of simplicity and with the idea that code should
>>> speak for itself(readable code and meaningful commit messages over dirty
>>> code covered by a detailed Jira issue).
>>>
>>> Now, given that, I have been using Jira for many years, I agree with all
>>> the limitations mentioned so far but I am generally happy about using it.
>>> I have limited experience with the Github issue system, it looks
>>> definitely "simpler" than Jira, not sure it covers all our requirements.
>>>
>>> Being a bit provocative and thinking out loud, I see a true necessity of
>>> raising issues(Jira or Github) in these instances:
>>> 1) proposal that needs discussion and doesn't have a clear solution
>>> 2) raise a bug/task/story we are not planning to do ourselves
>>> immediately (so we want to give the community the chance of doing it while
>>> we are busy)
>>> 3) planning, using sprints etc (we don't do)
>>>
>>> Whenever we have a contribution or bugfix ready (as an output of our
>>> daily working activity), it feels to me that it's unnecessary to create an
>>> issue at all, modern pull requests are perfectly fine for adding all the
>>> necessary details, tag people for review or discuss the contribution: to me
>>> having to open any kind of issue is just an unnecessary boilerplate
>>> activity (and duplication of description, comments, etc).
>>> Pretty sure I am missing something, but I just wanted to give a quick
>>> glance of a recent feeling of mine.
>>>
>>> Long story short, if the Github issue system covers all our
>>> requirements, I think it's going to be beneficial to keep all in the "same"
>>> place and would ease contributions.
>>> But I am arguing we should not open an issue for each contribution, most
>>> of the time the Pull Request should be enough.
>>> Of course, we should estimate the effort, identify people that
>>> realistically want to work for that and then vote if the amount of
>>> dedication is worth.
>>>
>>> In regards to nationality bans, and sanctions etc, I am personally not
>>> that worried, aren't we relying quite strongly already on Github for the
>>> repos, pull requests, etc?(and I assume many other infrastructures
>>> potentially owned by organizations that could impose certain bans?)
>>> Ideally, we want to just use tools owned by the Apache Software
>>> Foundation, but realistically sometimes you need to compromise.
>>> I would suggest we organize a voting session to see how strong the
>>> banning concern is, across the committers community, because generally, I
>>> think it's a fair point.
>>>
>>> Finally, I would like to raise a question:
>>> does anybody know if it's possible to create automatically "CHANGES" on
>>> GitHub, based on pull requests and merges maybe(or issues)?
>>> We were discussing removing the necessity of the (pretty annoying and
>>> error-prone) "CHANGES.txt", and wondering if Jira could automatically solve
>>> that necessity.
>>> If GitHub is better at that, could be a strong incentive to go in that
>>> direction!
>>>
>>> Cheers
>>>
>>>
>>>
>>> --------------------------
>>> *Alessandro Benedetti*
>>> CEO @ Sease Ltd.
>>> *Apache Lucene/Solr Committer*
>>> *Apache Solr PMC Member*
>>>
>>> e-mail: a.benedetti@sease.io
>>>
>>>
>>> *Sease* - Information Retrieval Applied
>>> Consulting | Training | Open Source
>>>
>>> Website: Sease.io <http://sease.io/>
>>> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter
>>> <https://twitter.com/seaseltd> | Youtube
>>> <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github
>>> <https://github.com/seaseltd>
>>>
>>>
>>> On Tue, 10 May 2022 at 06:04, Tomoko Uchida <
>>> tomoko.uchida.1111@gmail.com> wrote:
>>>
>>>> I'll keep open this thread for a while - while almost all concern for
>>>> the transition seems to be already on the table, I feel we'd need more
>>>> participation from committers who actively work for this project. Without
>>>> mature discussion among active committers and contributors, the vote would
>>>> not yield a good result whether it is passed or not.
>>>>
>>>> I don't want to disturb the coming release so I'm not going to move
>>>> this until the 9.2 release is done; but please feel free to leave comments.
>>>>
>>>> Tomoko
>>>>
>>>>
>>>> 2022?5?10?(?) 11:06 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>>>
>>>>> Thank you Robert for your feedback.
>>>>>
>>>>> I'm also sorry if my previous mail was urging explicit feedback - I
>>>>> understand such a request goes against the "lazy consensus" practice in
>>>>> Apache.
>>>>> I'd be grateful to hear thoughts or simply +1 / -1 / +-0 from
>>>>> developers who are actually affected by this proposal if you are interested.
>>>>>
>>>>> Thanks,
>>>>> Tomoko
>>>>>
>>>>>
>>>>> 2022?5?10?(?) 9:36 Robert Muir <rcmuir@gmail.com>:
>>>>>
>>>>>> On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida
>>>>>> <tomoko.uchida.1111@gmail.com> wrote:
>>>>>> >
>>>>>> > Also, I have a great deal to be concerned about "what active
>>>>>> committers/contributors on Lucene actually think of it".
>>>>>> >
>>>>>>
>>>>>> I have a couple thoughts.
>>>>>>
>>>>>> 1. What percentage of contributions are done via pull requests versus
>>>>>> via patch files these days? I'm always happy to commit a patch, but I
>>>>>> just don't see them. I'm still happy to commit a patch sent to the
>>>>>> mailing list. I feel that requiring JIRA is just unnecessarily
>>>>>> invoking another tool, another signup process, unnecessary hurdle. If
>>>>>> someone wants to send a patch to the mailing list, e.g. from the user
>>>>>> list as part of a discussion, that's fine.
>>>>>> 2. Realistically, every committer actively merging/committing is using
>>>>>> github today already. This proposal doesn't make their life any more
>>>>>> difficult. They already have their github account setup. It makes life
>>>>>> easier for the *contributor*, which is what I want.
>>>>>> 3. Around concerns of github "censorship" and certain countries, this
>>>>>> doesn't affect public repositories, just private ones. It has to do
>>>>>> with sanctions and money and so on. I see you committed Persian
>>>>>> Stemmer from an Iranian contributor just this morning. This is not a
>>>>>> problem.
>>>>>> 4. Still along these lines, I tested this stuff from behind chinese
>>>>>> great firewall this morning, to have the full experience myself.
>>>>>> lucene.apache.org site is extremely fast, fastly CDN! github.com was
>>>>>> a
>>>>>> bit slower to load, but not terrible. Loading up JIRA
>>>>>> (issues.apache.org) was very slow, required both getting and drinking
>>>>>> another coffee. It is some machine out there in hetzner germany, which
>>>>>> may be the issue. At the same time, I think it is unreasonable to ask
>>>>>> infra to "cluster" the JIRA for better access around the world,
>>>>>> because that's absurdly scary from a technical perspective. So I'm
>>>>>> happy if we can streamline the contribution process and make it easier
>>>>>> for folks outside of US and europe.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org> wrote:

>
>>
> Most modern open source projects use Github Issues for their issue
> tracking, so it's definitely doable, and really what new
> users/contributors will be expecting. Also I see that much discussion is
> already done on PRs, and JIRAs are mainly there just for
> bureaucratic purposes. So I think it would be a wonderful direction to go
> in.
>
>
On that note, many such projects I find it more difficult to get clarity on
whether or not I'm affected by the issue, or in what version it was
resolved. Usually i can be achieved by clicking on the referenced commit,
and then inspecting what tags are on that commit, but it's several clicks
and a minute or two vs just looking at the field in Jira...

This can be made easier by using milestones as seen here (random example,
used gradle because it's a very large, healthy project):
https://github.com/gradle/gradle/issues/20182

But I've seen a lot of projects that don't do that... which probably colors
my view a bit.

-Gus

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

I recommend people take a look at the now deprecated helm project. It was
very difficult to land PRs because they had so much governance and
automation. For a data store as mature as SOLR, I would suggest it is
needed.

Many issues are worth a read: https://github.com/helm/helm

On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.heck@gmail.com> wrote:

>
>
> On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org>
> wrote:
>
>>
>>>
>> Most modern open source projects use Github Issues for their issue
>> tracking, so it's definitely doable, and really what new
>> users/contributors will be expecting. Also I see that much discussion is
>> already done on PRs, and JIRAs are mainly there just for
>> bureaucratic purposes. So I think it would be a wonderful direction to go
>> in.
>>
>>
> On that note, many such projects I find it more difficult to get clarity
> on whether or not I'm affected by the issue, or in what version it was
> resolved. Usually i can be achieved by clicking on the referenced commit,
> and then inspecting what tags are on that commit, but it's several clicks
> and a minute or two vs just looking at the field in Jira...
>
> This can be made easier by using milestones as seen here (random example,
> used gradle because it's a very large, healthy project):
> https://github.com/gradle/gradle/issues/20182
>
> But I've seen a lot of projects that don't do that... which probably
> colors my view a bit.
>
> -Gus
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>


--
Marcus Eagan

I'm not going to get into how the Github automation should be done, that's
a whole separate thread. But I agree too much automation can certainly be
annoying and a burden. You can see this a lot in the kubernetes repos (
https://github.com/kubernetes), though it does come with its reasons.

Kubernetes is a good example of a project MUCH bigger than Solr
successfully using Github Issues & PRs. So I don't really think it's a
question if Github is feature-rich enough to handle our use case, it's
pretty clear that it is. It will certainly be a change in process, but I
think that all of these very successful open source projects show that it's
a valid option for our projects. I think the ultimate questions are:

- Which will be easier for users to find relevant information?
- Which reduces the amount of bureaucracy needed to contribute to the
project?
- Which fits into the workflows of existing committers the best?

To me Github comes up on top, even though there are things that JIRA does
better.

P.S. I think you mean https://github.com/helm/charts, marcus. I don't think
helm is deprecated

On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <marcuseagan@gmail.com> wrote:

> I recommend people take a look at the now deprecated helm project. It was
> very difficult to land PRs because they had so much governance and
> automation. For a data store as mature as SOLR, I would suggest it is
> needed.
>
> Many issues are worth a read: https://github.com/helm/helm
>
> On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.heck@gmail.com> wrote:
>
>>
>>
>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org>
>> wrote:
>>
>>>
>>>>
>>> Most modern open source projects use Github Issues for their issue
>>> tracking, so it's definitely doable, and really what new
>>> users/contributors will be expecting. Also I see that much discussion is
>>> already done on PRs, and JIRAs are mainly there just for
>>> bureaucratic purposes. So I think it would be a wonderful direction to go
>>> in.
>>>
>>>
>> On that note, many such projects I find it more difficult to get clarity
>> on whether or not I'm affected by the issue, or in what version it was
>> resolved. Usually i can be achieved by clicking on the referenced commit,
>> and then inspecting what tags are on that commit, but it's several clicks
>> and a minute or two vs just looking at the field in Jira...
>>
>> This can be made easier by using milestones as seen here (random example,
>> used gradle because it's a very large, healthy project):
>> https://github.com/gradle/gradle/issues/20182
>>
>> But I've seen a lot of projects that don't do that... which probably
>> colors my view a bit.
>>
>> -Gus
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>
>
> --
> Marcus Eagan
>
>

I don't have much to add to the (already very detailed!) discussion, just
wanted to add my support for the idea of moving to GitHub. I've had a good
experience with GitHub issues for other repos I contribute to and find the
mark-up language comfortable and expressive. I also think switching to
GitHub could help newer contributors engage with the project. When I first
started contributing I found it really hard to navigate and search JIRA for
issues I was interested in. Now I rely on Mike's wonderful JIRA search tool
(https://jirasearch.mikemccandless.com/search.py), but most new
contributors do not know about it (and it adds another dependency on top of
GitHub and JIRA).

Julie

On Tue, May 10, 2022 at 12:41 PM Houston Putman <houston@apache.org> wrote:

> I'm not going to get into how the Github automation should be done, that's
> a whole separate thread. But I agree too much automation can certainly be
> annoying and a burden. You can see this a lot in the kubernetes repos (
> https://github.com/kubernetes), though it does come with its reasons.
>
> Kubernetes is a good example of a project MUCH bigger than Solr
> successfully using Github Issues & PRs. So I don't really think it's a
> question if Github is feature-rich enough to handle our use case, it's
> pretty clear that it is. It will certainly be a change in process, but I
> think that all of these very successful open source projects show that it's
> a valid option for our projects. I think the ultimate questions are:
>
> - Which will be easier for users to find relevant information?
> - Which reduces the amount of bureaucracy needed to contribute to the
> project?
> - Which fits into the workflows of existing committers the best?
>
> To me Github comes up on top, even though there are things that JIRA does
> better.
>
> P.S. I think you mean https://github.com/helm/charts, marcus. I don't
> think helm is deprecated
>
> On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <marcuseagan@gmail.com>
> wrote:
>
>> I recommend people take a look at the now deprecated helm project. It was
>> very difficult to land PRs because they had so much governance and
>> automation. For a data store as mature as SOLR, I would suggest it is
>> needed.
>>
>> Many issues are worth a read: https://github.com/helm/helm
>>
>> On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.heck@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org>
>>> wrote:
>>>
>>>>
>>>>>
>>>> Most modern open source projects use Github Issues for their issue
>>>> tracking, so it's definitely doable, and really what new
>>>> users/contributors will be expecting. Also I see that much discussion is
>>>> already done on PRs, and JIRAs are mainly there just for
>>>> bureaucratic purposes. So I think it would be a wonderful direction to go
>>>> in.
>>>>
>>>>
>>> On that note, many such projects I find it more difficult to get clarity
>>> on whether or not I'm affected by the issue, or in what version it was
>>> resolved. Usually i can be achieved by clicking on the referenced commit,
>>> and then inspecting what tags are on that commit, but it's several clicks
>>> and a minute or two vs just looking at the field in Jira...
>>>
>>> This can be made easier by using milestones as seen here (random
>>> example, used gradle because it's a very large, healthy project):
>>> https://github.com/gradle/gradle/issues/20182
>>>
>>> But I've seen a lot of projects that don't do that... which probably
>>> colors my view a bit.
>>>
>>> -Gus
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>
>>
>> --
>> Marcus Eagan
>>
>>

Thanks everyone for your thoughtful comments - I think we can learn a lot
from Solr Operator project.

And then, I'd appreciate the feedback from Julie; not only because of the
support for the migration but also because we surely need feedback from
committers/contributors who actively create or review patches/PRs on a
regular basis and drives this project like you.
Of course, advisory comments from the whole community are really helpful
and I welcome feedback from all developers, regardless of the activities on
Lucene.

I don't think I'm good at facilitation, I'll try to be here though :)
I hope we'll continue a good conversation, and then, we can be confident
opening the official vote.

Tomoko


2022?5?11?(?) 9:36 Julie Tibshirani <julietibs@gmail.com>:

> I don't have much to add to the (already very detailed!) discussion, just
> wanted to add my support for the idea of moving to GitHub. I've had a good
> experience with GitHub issues for other repos I contribute to and find the
> mark-up language comfortable and expressive. I also think switching to
> GitHub could help newer contributors engage with the project. When I first
> started contributing I found it really hard to navigate and search JIRA for
> issues I was interested in. Now I rely on Mike's wonderful JIRA search tool
> (https://jirasearch.mikemccandless.com/search.py), but most new
> contributors do not know about it (and it adds another dependency on top of
> GitHub and JIRA).
>
> Julie
>
> On Tue, May 10, 2022 at 12:41 PM Houston Putman <houston@apache.org>
> wrote:
>
>> I'm not going to get into how the Github automation should be done,
>> that's a whole separate thread. But I agree too much automation can
>> certainly be annoying and a burden. You can see this a lot in the
>> kubernetes repos (https://github.com/kubernetes), though it does come
>> with its reasons.
>>
>> Kubernetes is a good example of a project MUCH bigger than Solr
>> successfully using Github Issues & PRs. So I don't really think it's a
>> question if Github is feature-rich enough to handle our use case, it's
>> pretty clear that it is. It will certainly be a change in process, but I
>> think that all of these very successful open source projects show that it's
>> a valid option for our projects. I think the ultimate questions are:
>>
>> - Which will be easier for users to find relevant information?
>> - Which reduces the amount of bureaucracy needed to contribute to the
>> project?
>> - Which fits into the workflows of existing committers the best?
>>
>> To me Github comes up on top, even though there are things that JIRA does
>> better.
>>
>> P.S. I think you mean https://github.com/helm/charts, marcus. I don't
>> think helm is deprecated
>>
>> On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <marcuseagan@gmail.com>
>> wrote:
>>
>>> I recommend people take a look at the now deprecated helm project. It
>>> was very difficult to land PRs because they had so much governance and
>>> automation. For a data store as mature as SOLR, I would suggest it is
>>> needed.
>>>
>>> Many issues are worth a read: https://github.com/helm/helm
>>>
>>> On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.heck@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org>
>>>> wrote:
>>>>
>>>>>
>>>>>>
>>>>> Most modern open source projects use Github Issues for their issue
>>>>> tracking, so it's definitely doable, and really what new
>>>>> users/contributors will be expecting. Also I see that much discussion is
>>>>> already done on PRs, and JIRAs are mainly there just for
>>>>> bureaucratic purposes. So I think it would be a wonderful direction to go
>>>>> in.
>>>>>
>>>>>
>>>> On that note, many such projects I find it more difficult to get
>>>> clarity on whether or not I'm affected by the issue, or in what version it
>>>> was resolved. Usually i can be achieved by clicking on the referenced
>>>> commit, and then inspecting what tags are on that commit, but it's several
>>>> clicks and a minute or two vs just looking at the field in Jira...
>>>>
>>>> This can be made easier by using milestones as seen here (random
>>>> example, used gradle because it's a very large, healthy project):
>>>> https://github.com/gradle/gradle/issues/20182
>>>>
>>>> But I've seen a lot of projects that don't do that... which probably
>>>> colors my view a bit.
>>>>
>>>> -Gus
>>>>
>>>> --
>>>> http://www.needhamsoftware.com (work)
>>>> http://www.the111shift.com (play)
>>>>
>>>
>>>
>>> --
>>> Marcus Eagan
>>>
>>>

The top reason for me to support moving our project to GitHub is to lower
friction for the growth of the Lucene developer community.

I myself am far less comfortable with GitHub issues than Jira, but that's
really unimportant. I can and will figure it out (like highlighting text
and hitting "r", yay!). I would hope/expect the same for all "old-timers"
here :)

Our community grows only at its periphery, with younger, passionate
people (who generally have strong comfort in GitHub and not with Jira).

Anything and everything we can do to reduce the friction for such Fresh
Eyes / Shoshin / ?? users, we must do. The long-term survival of our
(currently still vibrant, but that can change) community relies on
continued growth by doing everything possible to encourage new users,
growing to contributors, to committers, to PMC members, to Apache members.
I put this in the same bucket as "try to promptly respond to new people who
send emails to our lists" and "aggressively try to fix the silly issues a
new contributor hits" (like the recent "gradlew tidy" improvements from
Rich Bowen's "the the" first Lucene contribution).

Fresh Eyes is a sharp tool that quickly dulls, and we old-timers can no
longer sense nor appreciate/empathize-with the problems new contributors
hit, to our ("whole Lucene dev community") detriment.

Also, I really do not like that Jira silently blocks your IP if you try to
add a link to an external PDF that has the word "dissertation" in it! This
leads to confusion (especially if you are coming through a VPN since that
VPN's endpoint is blocked so anyone else sharing that endpoint, later, will
also see the silently dropped packets (spinning browser) when trying to add
comments to Jira). This is just a pet peeve LOL. Also, Apache's slow
adoption/enabling of modern Jira features like supporting Markdown does not
help the Jira case, also a pet peeve!

But big +1 on ensuring we can always recover all of our (future) GitHub
issues + metadata in the future event where we suddenly decide to move to
something else. This should not be a one-way door, and as part of the VOTE
process, we should do our best to confirm this.

I also feel it is vital we are able to migrate our full Jira issue history
to GitHub issues. Dawid's (herculean) efforts to preserve our full
Subversion history on moving to git was incredible and really vital. To
this day, you can "git log" and at the very bottom you see the first few
Lucene commits (under Apache Jakarta from 2001, on migrating from
SourceForge)! Lucene is a unique open-source project, with SO much
history, still so vibrant after so much time, surviving crazy JVM/JDK bugs,
and its widespread and growing adoption now. We must preserve that
history: it is a vital part of Lucene's current appeal and growth. Those
who do not study history are doomed to repeat it! We should not
intentionally throw our history away. So I will (most likely) VOTE -1 if
we cannot preserve our detailed Jira issue history on migration, and
likewise if we cannot do so (based on our best prediction) in the future on
migration from GitHub issues to elsewhere.

Mike McCandless

http://blog.mikemccandless.com


On Wed, May 11, 2022 at 12:58 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> Thanks everyone for your thoughtful comments - I think we can learn a lot
> from Solr Operator project.
>
> And then, I'd appreciate the feedback from Julie; not only because of the
> support for the migration but also because we surely need feedback from
> committers/contributors who actively create or review patches/PRs on a
> regular basis and drives this project like you.
> Of course, advisory comments from the whole community are really helpful
> and I welcome feedback from all developers, regardless of the activities on
> Lucene.
>
> I don't think I'm good at facilitation, I'll try to be here though :)
> I hope we'll continue a good conversation, and then, we can be confident
> opening the official vote.
>
> Tomoko
>
>
> 2022?5?11?(?) 9:36 Julie Tibshirani <julietibs@gmail.com>:
>
>> I don't have much to add to the (already very detailed!) discussion, just
>> wanted to add my support for the idea of moving to GitHub. I've had a good
>> experience with GitHub issues for other repos I contribute to and find the
>> mark-up language comfortable and expressive. I also think switching to
>> GitHub could help newer contributors engage with the project. When I first
>> started contributing I found it really hard to navigate and search JIRA for
>> issues I was interested in. Now I rely on Mike's wonderful JIRA search tool
>> (https://jirasearch.mikemccandless.com/search.py), but most new
>> contributors do not know about it (and it adds another dependency on top of
>> GitHub and JIRA).
>>
>> Julie
>>
>> On Tue, May 10, 2022 at 12:41 PM Houston Putman <houston@apache.org>
>> wrote:
>>
>>> I'm not going to get into how the Github automation should be done,
>>> that's a whole separate thread. But I agree too much automation can
>>> certainly be annoying and a burden. You can see this a lot in the
>>> kubernetes repos (https://github.com/kubernetes), though it does come
>>> with its reasons.
>>>
>>> Kubernetes is a good example of a project MUCH bigger than Solr
>>> successfully using Github Issues & PRs. So I don't really think it's a
>>> question if Github is feature-rich enough to handle our use case, it's
>>> pretty clear that it is. It will certainly be a change in process, but I
>>> think that all of these very successful open source projects show that it's
>>> a valid option for our projects. I think the ultimate questions are:
>>>
>>> - Which will be easier for users to find relevant information?
>>> - Which reduces the amount of bureaucracy needed to contribute to
>>> the project?
>>> - Which fits into the workflows of existing committers the best?
>>>
>>> To me Github comes up on top, even though there are things that JIRA
>>> does better.
>>>
>>> P.S. I think you mean https://github.com/helm/charts, marcus. I don't
>>> think helm is deprecated
>>>
>>> On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <marcuseagan@gmail.com>
>>> wrote:
>>>
>>>> I recommend people take a look at the now deprecated helm project. It
>>>> was very difficult to land PRs because they had so much governance and
>>>> automation. For a data store as mature as SOLR, I would suggest it is
>>>> needed.
>>>>
>>>> Many issues are worth a read: https://github.com/helm/helm
>>>>
>>>> On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.heck@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>
>>>>>> Most modern open source projects use Github Issues for their issue
>>>>>> tracking, so it's definitely doable, and really what new
>>>>>> users/contributors will be expecting. Also I see that much discussion is
>>>>>> already done on PRs, and JIRAs are mainly there just for
>>>>>> bureaucratic purposes. So I think it would be a wonderful direction to go
>>>>>> in.
>>>>>>
>>>>>>
>>>>> On that note, many such projects I find it more difficult to get
>>>>> clarity on whether or not I'm affected by the issue, or in what version it
>>>>> was resolved. Usually i can be achieved by clicking on the referenced
>>>>> commit, and then inspecting what tags are on that commit, but it's several
>>>>> clicks and a minute or two vs just looking at the field in Jira...
>>>>>
>>>>> This can be made easier by using milestones as seen here (random
>>>>> example, used gradle because it's a very large, healthy project):
>>>>> https://github.com/gradle/gradle/issues/20182
>>>>>
>>>>> But I've seen a lot of projects that don't do that... which probably
>>>>> colors my view a bit.
>>>>>
>>>>> -Gus
>>>>>
>>>>> --
>>>>> http://www.needhamsoftware.com (work)
>>>>> http://www.the111shift.com (play)
>>>>>
>>>>
>>>>
>>>> --
>>>> Marcus Eagan
>>>>
>>>>

Thank you Mike for your support and comment.

> I also feel it is vital we are able to migrate our full Jira issue
history to GitHub issues. Dawid's (herculean) efforts to preserve our full
Subversion history on moving to git was incredible and really vital. To
this day, you can "git log" and at the very bottom you see the first few
Lucene commits (under Apache Jakarta from 2001, on migrating from
SourceForge)! Lucene is a unique open-source project, with SO much
history, still so vibrant after so much time, surviving crazy JVM/JDK bugs,
and its widespread and growing adoption now. We must preserve that
history: it is a vital part of Lucene's current appeal and growth. Those
who do not study history are doomed to repeat it! We should not
intentionally throw our history away. So I will (most likely) VOTE -1 if
we cannot preserve our detailed Jira issue history on migration, and
likewise if we cannot do so (based on our best prediction) in the future on
migration from GitHub issues to elsewhere.

I'm just curious - all Jira issues always will be there and accessible from
anywhere (at least in a readable state), and we can reach them from our
CHANGES anytime. They won't be lost, and of course, we can link to Jira
issues from GitHub issues for tracking their history/background. So - what
is the point of "preserve our detailed Jira issue history on migration" in
GitHub?
I understand the code and commit history are our most important assets, and
the effort to preserve them in a whole, linear history perfectly makes
sense to me. On the other hand, issues are in slightly different context
from commit history, I think.

Personally, I don't believe automate migration tools between proprietary
services - I'm almost sure there will be some information losses if we
attempt to migrate the whole Jira issue into Github... Rather than trying
to do that, I would prefer to let Jira issues as is, then simply refer them.
(I'm not so knowledgeable, so correct me if there are perfectly reliable
tools for Jira -> GitHub migration.)

If we need a federated search for both Jira and GitHub, I think we already
have a great one - https://jirasearch.mikemccandless.com/search.py

Tomoko


2022?5?12?(?) 0:09 Michael McCandless <lucene@mikemccandless.com>:

> The top reason for me to support moving our project to GitHub is to lower
> friction for the growth of the Lucene developer community.
>
> I myself am far less comfortable with GitHub issues than Jira, but that's
> really unimportant. I can and will figure it out (like highlighting text
> and hitting "r", yay!). I would hope/expect the same for all "old-timers"
> here :)
>
> Our community grows only at its periphery, with younger, passionate
> people (who generally have strong comfort in GitHub and not with Jira).
>
> Anything and everything we can do to reduce the friction for such Fresh
> Eyes / Shoshin / ?? users, we must do. The long-term survival of our
> (currently still vibrant, but that can change) community relies on
> continued growth by doing everything possible to encourage new users,
> growing to contributors, to committers, to PMC members, to Apache members.
> I put this in the same bucket as "try to promptly respond to new people who
> send emails to our lists" and "aggressively try to fix the silly issues a
> new contributor hits" (like the recent "gradlew tidy" improvements from
> Rich Bowen's "the the" first Lucene contribution).
>
> Fresh Eyes is a sharp tool that quickly dulls, and we old-timers can no
> longer sense nor appreciate/empathize-with the problems new contributors
> hit, to our ("whole Lucene dev community") detriment.
>
> Also, I really do not like that Jira silently blocks your IP if you try to
> add a link to an external PDF that has the word "dissertation" in it! This
> leads to confusion (especially if you are coming through a VPN since that
> VPN's endpoint is blocked so anyone else sharing that endpoint, later, will
> also see the silently dropped packets (spinning browser) when trying to add
> comments to Jira). This is just a pet peeve LOL. Also, Apache's slow
> adoption/enabling of modern Jira features like supporting Markdown does not
> help the Jira case, also a pet peeve!
>
> But big +1 on ensuring we can always recover all of our (future) GitHub
> issues + metadata in the future event where we suddenly decide to move to
> something else. This should not be a one-way door, and as part of the VOTE
> process, we should do our best to confirm this.
>
> I also feel it is vital we are able to migrate our full Jira issue history
> to GitHub issues. Dawid's (herculean) efforts to preserve our full
> Subversion history on moving to git was incredible and really vital. To
> this day, you can "git log" and at the very bottom you see the first few
> Lucene commits (under Apache Jakarta from 2001, on migrating from
> SourceForge)! Lucene is a unique open-source project, with SO much
> history, still so vibrant after so much time, surviving crazy JVM/JDK bugs,
> and its widespread and growing adoption now. We must preserve that
> history: it is a vital part of Lucene's current appeal and growth. Those
> who do not study history are doomed to repeat it! We should not
> intentionally throw our history away. So I will (most likely) VOTE -1 if
> we cannot preserve our detailed Jira issue history on migration, and
> likewise if we cannot do so (based on our best prediction) in the future on
> migration from GitHub issues to elsewhere.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, May 11, 2022 at 12:58 AM Tomoko Uchida <
> tomoko.uchida.1111@gmail.com> wrote:
>
>> Thanks everyone for your thoughtful comments - I think we can learn a lot
>> from Solr Operator project.
>>
>> And then, I'd appreciate the feedback from Julie; not only because of the
>> support for the migration but also because we surely need feedback from
>> committers/contributors who actively create or review patches/PRs on a
>> regular basis and drives this project like you.
>> Of course, advisory comments from the whole community are really helpful
>> and I welcome feedback from all developers, regardless of the activities on
>> Lucene.
>>
>> I don't think I'm good at facilitation, I'll try to be here though :)
>> I hope we'll continue a good conversation, and then, we can be confident
>> opening the official vote.
>>
>> Tomoko
>>
>>
>> 2022?5?11?(?) 9:36 Julie Tibshirani <julietibs@gmail.com>:
>>
>>> I don't have much to add to the (already very detailed!) discussion,
>>> just wanted to add my support for the idea of moving to GitHub. I've had a
>>> good experience with GitHub issues for other repos I contribute to and find
>>> the mark-up language comfortable and expressive. I also think switching to
>>> GitHub could help newer contributors engage with the project. When I first
>>> started contributing I found it really hard to navigate and search JIRA for
>>> issues I was interested in. Now I rely on Mike's wonderful JIRA search tool
>>> (https://jirasearch.mikemccandless.com/search.py), but most new
>>> contributors do not know about it (and it adds another dependency on top of
>>> GitHub and JIRA).
>>>
>>> Julie
>>>
>>> On Tue, May 10, 2022 at 12:41 PM Houston Putman <houston@apache.org>
>>> wrote:
>>>
>>>> I'm not going to get into how the Github automation should be done,
>>>> that's a whole separate thread. But I agree too much automation can
>>>> certainly be annoying and a burden. You can see this a lot in the
>>>> kubernetes repos (https://github.com/kubernetes), though it does come
>>>> with its reasons.
>>>>
>>>> Kubernetes is a good example of a project MUCH bigger than Solr
>>>> successfully using Github Issues & PRs. So I don't really think it's a
>>>> question if Github is feature-rich enough to handle our use case, it's
>>>> pretty clear that it is. It will certainly be a change in process, but I
>>>> think that all of these very successful open source projects show that it's
>>>> a valid option for our projects. I think the ultimate questions are:
>>>>
>>>> - Which will be easier for users to find relevant information?
>>>> - Which reduces the amount of bureaucracy needed to contribute to
>>>> the project?
>>>> - Which fits into the workflows of existing committers the best?
>>>>
>>>> To me Github comes up on top, even though there are things that JIRA
>>>> does better.
>>>>
>>>> P.S. I think you mean https://github.com/helm/charts, marcus. I don't
>>>> think helm is deprecated
>>>>
>>>> On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <marcuseagan@gmail.com>
>>>> wrote:
>>>>
>>>>> I recommend people take a look at the now deprecated helm project. It
>>>>> was very difficult to land PRs because they had so much governance and
>>>>> automation. For a data store as mature as SOLR, I would suggest it is
>>>>> needed.
>>>>>
>>>>> Many issues are worth a read: https://github.com/helm/helm
>>>>>
>>>>> On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.heck@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>> Most modern open source projects use Github Issues for their issue
>>>>>>> tracking, so it's definitely doable, and really what new
>>>>>>> users/contributors will be expecting. Also I see that much discussion is
>>>>>>> already done on PRs, and JIRAs are mainly there just for
>>>>>>> bureaucratic purposes. So I think it would be a wonderful direction to go
>>>>>>> in.
>>>>>>>
>>>>>>>
>>>>>> On that note, many such projects I find it more difficult to get
>>>>>> clarity on whether or not I'm affected by the issue, or in what version it
>>>>>> was resolved. Usually i can be achieved by clicking on the referenced
>>>>>> commit, and then inspecting what tags are on that commit, but it's several
>>>>>> clicks and a minute or two vs just looking at the field in Jira...
>>>>>>
>>>>>> This can be made easier by using milestones as seen here (random
>>>>>> example, used gradle because it's a very large, healthy project):
>>>>>> https://github.com/gradle/gradle/issues/20182
>>>>>>
>>>>>> But I've seen a lot of projects that don't do that... which probably
>>>>>> colors my view a bit.
>>>>>>
>>>>>> -Gus
>>>>>>
>>>>>> --
>>>>>> http://www.needhamsoftware.com (work)
>>>>>> http://www.the111shift.com (play)
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Marcus Eagan
>>>>>
>>>>>

>
> But big +1 on ensuring we can always recover all of our (future) GitHub
> issues + metadata in the future event where we suddenly decide to move to
> something else. This should not be a one-way door, and as part of the VOTE
> process, we should do our best to confirm this.
>
>
This caused me to think about something.. issues -> issues on the way in
issues -> issues on the way out, but what happens to PR's on the way out?
This would sort of mean that the only systems we could move to in the
future are systems to which we can migrate PRs?

Another thing to think about is branch cleanup vs PR's if the discussion is
in PR's we need to keep all the branches? (which I generally favor in the
first place, but I've seen folks want to clean up old branches)


> I also feel it is vital we are able to migrate our full Jira issue history
> to GitHub issues. Dawid's (herculean) efforts to preserve our full
> Subversion history on moving to git was incredible and really vital. To
> this day, you can "git log" and at the very bottom you see the first few
> Lucene commits (under Apache Jakarta from 2001, on migrating from
> SourceForge)! Lucene is a unique open-source project, with SO much
> history, still so vibrant after so much time, surviving crazy JVM/JDK bugs,
> and its widespread and growing adoption now. We must preserve that
> history: it is a vital part of Lucene's current appeal and growth. Those
> who do not study history are doomed to repeat it! We should not
> intentionally throw our history away. So I will (most likely) VOTE -1 if
> we cannot preserve our detailed Jira issue history on migration, and
> likewise if we cannot do so (based on our best prediction) in the future on
> migration from GitHub issues to elsewhere.
>

Yes history is super important, and actually I have (prior to this
discussion) worried that the use of PR's in our current state has made the
history/discussion a little harder to understand, but line focused comments
are obviously also super good, so I've felt conflicted there.


>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, May 11, 2022 at 12:58 AM Tomoko Uchida <
> tomoko.uchida.1111@gmail.com> wrote:
>
>> Thanks everyone for your thoughtful comments - I think we can learn a lot
>> from Solr Operator project.
>>
>> And then, I'd appreciate the feedback from Julie; not only because of the
>> support for the migration but also because we surely need feedback from
>> committers/contributors who actively create or review patches/PRs on a
>> regular basis and drives this project like you.
>> Of course, advisory comments from the whole community are really helpful
>> and I welcome feedback from all developers, regardless of the activities on
>> Lucene.
>>
>> I don't think I'm good at facilitation, I'll try to be here though :)
>> I hope we'll continue a good conversation, and then, we can be confident
>> opening the official vote.
>>
>> Tomoko
>>
>>
>> 2022?5?11?(?) 9:36 Julie Tibshirani <julietibs@gmail.com>:
>>
>>> I don't have much to add to the (already very detailed!) discussion,
>>> just wanted to add my support for the idea of moving to GitHub. I've had a
>>> good experience with GitHub issues for other repos I contribute to and find
>>> the mark-up language comfortable and expressive. I also think switching to
>>> GitHub could help newer contributors engage with the project. When I first
>>> started contributing I found it really hard to navigate and search JIRA for
>>> issues I was interested in. Now I rely on Mike's wonderful JIRA search tool
>>> (https://jirasearch.mikemccandless.com/search.py), but most new
>>> contributors do not know about it (and it adds another dependency on top of
>>> GitHub and JIRA).
>>>
>>> Julie
>>>
>>> On Tue, May 10, 2022 at 12:41 PM Houston Putman <houston@apache.org>
>>> wrote:
>>>
>>>> I'm not going to get into how the Github automation should be done,
>>>> that's a whole separate thread. But I agree too much automation can
>>>> certainly be annoying and a burden. You can see this a lot in the
>>>> kubernetes repos (https://github.com/kubernetes), though it does come
>>>> with its reasons.
>>>>
>>>> Kubernetes is a good example of a project MUCH bigger than Solr
>>>> successfully using Github Issues & PRs. So I don't really think it's a
>>>> question if Github is feature-rich enough to handle our use case, it's
>>>> pretty clear that it is. It will certainly be a change in process, but I
>>>> think that all of these very successful open source projects show that it's
>>>> a valid option for our projects. I think the ultimate questions are:
>>>>
>>>> - Which will be easier for users to find relevant information?
>>>> - Which reduces the amount of bureaucracy needed to contribute to
>>>> the project?
>>>> - Which fits into the workflows of existing committers the best?
>>>>
>>>> To me Github comes up on top, even though there are things that JIRA
>>>> does better.
>>>>
>>>> P.S. I think you mean https://github.com/helm/charts, marcus. I don't
>>>> think helm is deprecated
>>>>
>>>> On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <marcuseagan@gmail.com>
>>>> wrote:
>>>>
>>>>> I recommend people take a look at the now deprecated helm project. It
>>>>> was very difficult to land PRs because they had so much governance and
>>>>> automation. For a data store as mature as SOLR, I would suggest it is
>>>>> needed.
>>>>>
>>>>> Many issues are worth a read: https://github.com/helm/helm
>>>>>
>>>>> On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.heck@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>> Most modern open source projects use Github Issues for their issue
>>>>>>> tracking, so it's definitely doable, and really what new
>>>>>>> users/contributors will be expecting. Also I see that much discussion is
>>>>>>> already done on PRs, and JIRAs are mainly there just for
>>>>>>> bureaucratic purposes. So I think it would be a wonderful direction to go
>>>>>>> in.
>>>>>>>
>>>>>>>
>>>>>> On that note, many such projects I find it more difficult to get
>>>>>> clarity on whether or not I'm affected by the issue, or in what version it
>>>>>> was resolved. Usually i can be achieved by clicking on the referenced
>>>>>> commit, and then inspecting what tags are on that commit, but it's several
>>>>>> clicks and a minute or two vs just looking at the field in Jira...
>>>>>>
>>>>>> This can be made easier by using milestones as seen here (random
>>>>>> example, used gradle because it's a very large, healthy project):
>>>>>> https://github.com/gradle/gradle/issues/20182
>>>>>>
>>>>>> But I've seen a lot of projects that don't do that... which probably
>>>>>> colors my view a bit.
>>>>>>
>>>>>> -Gus
>>>>>>
>>>>>> --
>>>>>> http://www.needhamsoftware.com (work)
>>>>>> http://www.the111shift.com (play)
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Marcus Eagan
>>>>>
>>>>>

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

We have been having a very long discussion many issues are posed, thank you
everyone who is involved.
Here is a short, non-exhaustive summary of posed issues/questions (with my
brief thoughts/opinions) so far.

* Concerns for political neutrality of GitHub - in other words, concerns
for account bans with no good reason
** Seems there are several cases of GitHub account bans. It's unclear
whether they violated its terms of policy or not, and to me, we won't be
able to correctly assess the risk. I would defer the judgment to the
individuals.
** For developers who don't use GitHub for whatever reason, we will
always support contribution paths that do not rely on GitHub. Patches via
Jira will be a decent option for good.

* Concerns for its parent company, Microsoft
** I'd defer the judgment on that to the individuals for the same
reason for the previous subject. One thing I could say is, that the recent
trend in their direction is GOOD - they support/sponsor open source and
Java communities and even publish very popular open-source software (VSCode
and LightGBM are outstanding examples I think).

* Concerns for lack of issue workflow and simpler metadata management
** From the practical viewpoint, it fully makes sense to me that many
people talked about it. We would need to carefully think of how to control
versions and issue/PR metadata. Large projects that are fully operated on
GitHub overcome this shortcoming in various ways - organized issue
templates with fixed label sets would be an example. I think we will have a
sandbox repository outside ASF, then try some experiments on it before
actual migration.

* Security issues that only PMC members are allowed to be accessed
** We will be able to continue to use Jira for this purpose, or we
could even have an issue-only private GitHub repository for Lucene?

* Concerns for migration of whole existing Jira issue history to GitHub
issue
** I don't think it is possible. I'm almost sure there will be some
information losses if we attempt to migrate the whole Jira issue with
metadata/history into Github. Rather than trying to do that, I would prefer
to let Jira issues as is, then simply refer them.
** If we don't aim at perfection, I think we'll be able to migrate all
(or part of) issues with APIs as Shad Storhaug kindly shared in the issue
comment[1].

[1]
https://issues.apache.org/jira/browse/LUCENE-10557?focusedCommentId=17535898&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17535898

Aside from those concerns, there seems no disagreement with GitHub is
superior to Jira in terms of overall UX design, and most new developers
like it.

I'm planning to make a VOTE thread but before that, I'll do some surveys on
Jira issue stats (# of total issues, # of unresolved issues, etc.) and
large/popular projects that are hosted on GitHub so that we can make a
clearer image on how things will be / should be done. This will take some
more time for me and in the meantime, I look forward to feedback on the
proposal (support or raising questions/issues, providing information,
whatever else) from others.

Tomoko


2022?5?12?(?) 1:29 Gus Heck <gus.heck@gmail.com>:

>
>
>
>>
>> But big +1 on ensuring we can always recover all of our (future) GitHub
>> issues + metadata in the future event where we suddenly decide to move to
>> something else. This should not be a one-way door, and as part of the VOTE
>> process, we should do our best to confirm this.
>>
>>
> This caused me to think about something.. issues -> issues on the way in
> issues -> issues on the way out, but what happens to PR's on the way out?
> This would sort of mean that the only systems we could move to in the
> future are systems to which we can migrate PRs?
>
> Another thing to think about is branch cleanup vs PR's if the discussion
> is in PR's we need to keep all the branches? (which I generally favor in
> the first place, but I've seen folks want to clean up old branches)
>
>
>> I also feel it is vital we are able to migrate our full Jira issue
>> history to GitHub issues. Dawid's (herculean) efforts to preserve our full
>> Subversion history on moving to git was incredible and really vital. To
>> this day, you can "git log" and at the very bottom you see the first few
>> Lucene commits (under Apache Jakarta from 2001, on migrating from
>> SourceForge)! Lucene is a unique open-source project, with SO much
>> history, still so vibrant after so much time, surviving crazy JVM/JDK bugs,
>> and its widespread and growing adoption now. We must preserve that
>> history: it is a vital part of Lucene's current appeal and growth. Those
>> who do not study history are doomed to repeat it! We should not
>> intentionally throw our history away. So I will (most likely) VOTE -1 if
>> we cannot preserve our detailed Jira issue history on migration, and
>> likewise if we cannot do so (based on our best prediction) in the future on
>> migration from GitHub issues to elsewhere.
>>
>
> Yes history is super important, and actually I have (prior to this
> discussion) worried that the use of PR's in our current state has made the
> history/discussion a little harder to understand, but line focused comments
> are obviously also super good, so I've felt conflicted there.
>
>
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Wed, May 11, 2022 at 12:58 AM Tomoko Uchida <
>> tomoko.uchida.1111@gmail.com> wrote:
>>
>>> Thanks everyone for your thoughtful comments - I think we can learn a
>>> lot from Solr Operator project.
>>>
>>> And then, I'd appreciate the feedback from Julie; not only because of
>>> the support for the migration but also because we surely need feedback from
>>> committers/contributors who actively create or review patches/PRs on a
>>> regular basis and drives this project like you.
>>> Of course, advisory comments from the whole community are really helpful
>>> and I welcome feedback from all developers, regardless of the activities on
>>> Lucene.
>>>
>>> I don't think I'm good at facilitation, I'll try to be here though :)
>>> I hope we'll continue a good conversation, and then, we can be confident
>>> opening the official vote.
>>>
>>> Tomoko
>>>
>>>
>>> 2022?5?11?(?) 9:36 Julie Tibshirani <julietibs@gmail.com>:
>>>
>>>> I don't have much to add to the (already very detailed!) discussion,
>>>> just wanted to add my support for the idea of moving to GitHub. I've had a
>>>> good experience with GitHub issues for other repos I contribute to and find
>>>> the mark-up language comfortable and expressive. I also think switching to
>>>> GitHub could help newer contributors engage with the project. When I first
>>>> started contributing I found it really hard to navigate and search JIRA for
>>>> issues I was interested in. Now I rely on Mike's wonderful JIRA search tool
>>>> (https://jirasearch.mikemccandless.com/search.py), but most new
>>>> contributors do not know about it (and it adds another dependency on top of
>>>> GitHub and JIRA).
>>>>
>>>> Julie
>>>>
>>>> On Tue, May 10, 2022 at 12:41 PM Houston Putman <houston@apache.org>
>>>> wrote:
>>>>
>>>>> I'm not going to get into how the Github automation should be done,
>>>>> that's a whole separate thread. But I agree too much automation can
>>>>> certainly be annoying and a burden. You can see this a lot in the
>>>>> kubernetes repos (https://github.com/kubernetes), though it does come
>>>>> with its reasons.
>>>>>
>>>>> Kubernetes is a good example of a project MUCH bigger than Solr
>>>>> successfully using Github Issues & PRs. So I don't really think it's a
>>>>> question if Github is feature-rich enough to handle our use case, it's
>>>>> pretty clear that it is. It will certainly be a change in process, but I
>>>>> think that all of these very successful open source projects show that it's
>>>>> a valid option for our projects. I think the ultimate questions are:
>>>>>
>>>>> - Which will be easier for users to find relevant information?
>>>>> - Which reduces the amount of bureaucracy needed to contribute to
>>>>> the project?
>>>>> - Which fits into the workflows of existing committers the best?
>>>>>
>>>>> To me Github comes up on top, even though there are things that JIRA
>>>>> does better.
>>>>>
>>>>> P.S. I think you mean https://github.com/helm/charts, marcus. I don't
>>>>> think helm is deprecated
>>>>>
>>>>> On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <marcuseagan@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I recommend people take a look at the now deprecated helm project. It
>>>>>> was very difficult to land PRs because they had so much governance and
>>>>>> automation. For a data store as mature as SOLR, I would suggest it is
>>>>>> needed.
>>>>>>
>>>>>> Many issues are worth a read: https://github.com/helm/helm
>>>>>>
>>>>>> On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.heck@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>> Most modern open source projects use Github Issues for their issue
>>>>>>>> tracking, so it's definitely doable, and really what new
>>>>>>>> users/contributors will be expecting. Also I see that much discussion is
>>>>>>>> already done on PRs, and JIRAs are mainly there just for
>>>>>>>> bureaucratic purposes. So I think it would be a wonderful direction to go
>>>>>>>> in.
>>>>>>>>
>>>>>>>>
>>>>>>> On that note, many such projects I find it more difficult to get
>>>>>>> clarity on whether or not I'm affected by the issue, or in what version it
>>>>>>> was resolved. Usually i can be achieved by clicking on the referenced
>>>>>>> commit, and then inspecting what tags are on that commit, but it's several
>>>>>>> clicks and a minute or two vs just looking at the field in Jira...
>>>>>>>
>>>>>>> This can be made easier by using milestones as seen here (random
>>>>>>> example, used gradle because it's a very large, healthy project):
>>>>>>> https://github.com/gradle/gradle/issues/20182
>>>>>>>
>>>>>>> But I've seen a lot of projects that don't do that... which probably
>>>>>>> colors my view a bit.
>>>>>>>
>>>>>>> -Gus
>>>>>>>
>>>>>>> --
>>>>>>> http://www.needhamsoftware.com (work)
>>>>>>> http://www.the111shift.com (play)
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Marcus Eagan
>>>>>>
>>>>>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>

Hi all,

I did some surveys on current Jira issue stats and operational policies on
other projects that are operated on GitHub.
Here's a summary.

[Issue stats on 28/May/2022]
# of total issues: 10543
# of unresolved issues: 1914

Breakdown of unresolved issues
By Issue Type
- Type="Bug": 679
- Type="Improvement": 790
- Type="New Feature": 173
- ...

You can see more detailed numbers on LUCENE-10557
<https://issues.apache.org/jira/browse/LUCENE-10557>.

[Operational policies in other projects on GitHub]
I randomly selected some large/popular projects including ASF projects for
this - Kubernetes, Elasticsearch, OpenSearch, Apache Solr Operator, Apache
Airflow, Apache Lucene.NET, Spring Framework, and Gradle.
I don't explain the whole details here, please see the issue comment on
LUCENE-10557.

And I drafted an early migration plan on the issue.

I'm going to close this discussion and open a vote next week - in the
meantime, please review the summaries of the conversation here on
LUCENE-10557 and join the vote.

I'd also like to set a local protocol for the vote.
There are 95 committers (including PMC members) [1] - the vote will be
effective if it successfully gains more than 15% of votes from committers
(>= 15) in a reasonable time period. Otherwise, I'll cancel the vote.
This means, that only PMC members' votes are counted for the final result,
but the votes of all committers are important to make the vote effective.
But why set such an extra bar? My fear is that if such things are decided
by the opinions of a few members, the result shouldn't yield a good result
for the future. It isn't my goal to just pass the vote.

[1] https://projects.apache.org/committee.html?lucene

Tomoko

Tomoko


2022?5?26?(?) 10:17 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:

> We have been having a very long discussion many issues are posed, thank
> you everyone who is involved.
> Here is a short, non-exhaustive summary of posed issues/questions (with my
> brief thoughts/opinions) so far.
>
> * Concerns for political neutrality of GitHub - in other words, concerns
> for account bans with no good reason
> ** Seems there are several cases of GitHub account bans. It's unclear
> whether they violated its terms of policy or not, and to me, we won't be
> able to correctly assess the risk. I would defer the judgment to the
> individuals.
> ** For developers who don't use GitHub for whatever reason, we will
> always support contribution paths that do not rely on GitHub. Patches via
> Jira will be a decent option for good.
>
> * Concerns for its parent company, Microsoft
> ** I'd defer the judgment on that to the individuals for the same
> reason for the previous subject. One thing I could say is, that the recent
> trend in their direction is GOOD - they support/sponsor open source and
> Java communities and even publish very popular open-source software (VSCode
> and LightGBM are outstanding examples I think).
>
> * Concerns for lack of issue workflow and simpler metadata management
> ** From the practical viewpoint, it fully makes sense to me that many
> people talked about it. We would need to carefully think of how to control
> versions and issue/PR metadata. Large projects that are fully operated on
> GitHub overcome this shortcoming in various ways - organized issue
> templates with fixed label sets would be an example. I think we will have a
> sandbox repository outside ASF, then try some experiments on it before
> actual migration.
>
> * Security issues that only PMC members are allowed to be accessed
> ** We will be able to continue to use Jira for this purpose, or we
> could even have an issue-only private GitHub repository for Lucene?
>
> * Concerns for migration of whole existing Jira issue history to GitHub
> issue
> ** I don't think it is possible. I'm almost sure there will be some
> information losses if we attempt to migrate the whole Jira issue with
> metadata/history into Github. Rather than trying to do that, I would prefer
> to let Jira issues as is, then simply refer them.
> ** If we don't aim at perfection, I think we'll be able to migrate all
> (or part of) issues with APIs as Shad Storhaug kindly shared in the issue
> comment[1].
>
> [1]
> https://issues.apache.org/jira/browse/LUCENE-10557?focusedCommentId=17535898&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17535898
>
> Aside from those concerns, there seems no disagreement with GitHub is
> superior to Jira in terms of overall UX design, and most new developers
> like it.
>
> I'm planning to make a VOTE thread but before that, I'll do some surveys
> on Jira issue stats (# of total issues, # of unresolved issues, etc.) and
> large/popular projects that are hosted on GitHub so that we can make a
> clearer image on how things will be / should be done. This will take some
> more time for me and in the meantime, I look forward to feedback on the
> proposal (support or raising questions/issues, providing information,
> whatever else) from others.
>
> Tomoko
>
>
> 2022?5?12?(?) 1:29 Gus Heck <gus.heck@gmail.com>:
>
>>
>>
>>
>>>
>>> But big +1 on ensuring we can always recover all of our (future) GitHub
>>> issues + metadata in the future event where we suddenly decide to move to
>>> something else. This should not be a one-way door, and as part of the VOTE
>>> process, we should do our best to confirm this.
>>>
>>>
>> This caused me to think about something.. issues -> issues on the way in
>> issues -> issues on the way out, but what happens to PR's on the way out?
>> This would sort of mean that the only systems we could move to in the
>> future are systems to which we can migrate PRs?
>>
>> Another thing to think about is branch cleanup vs PR's if the discussion
>> is in PR's we need to keep all the branches? (which I generally favor in
>> the first place, but I've seen folks want to clean up old branches)
>>
>>
>>> I also feel it is vital we are able to migrate our full Jira issue
>>> history to GitHub issues. Dawid's (herculean) efforts to preserve our full
>>> Subversion history on moving to git was incredible and really vital. To
>>> this day, you can "git log" and at the very bottom you see the first few
>>> Lucene commits (under Apache Jakarta from 2001, on migrating from
>>> SourceForge)! Lucene is a unique open-source project, with SO much
>>> history, still so vibrant after so much time, surviving crazy JVM/JDK bugs,
>>> and its widespread and growing adoption now. We must preserve that
>>> history: it is a vital part of Lucene's current appeal and growth. Those
>>> who do not study history are doomed to repeat it! We should not
>>> intentionally throw our history away. So I will (most likely) VOTE -1 if
>>> we cannot preserve our detailed Jira issue history on migration, and
>>> likewise if we cannot do so (based on our best prediction) in the future on
>>> migration from GitHub issues to elsewhere.
>>>
>>
>> Yes history is super important, and actually I have (prior to this
>> discussion) worried that the use of PR's in our current state has made the
>> history/discussion a little harder to understand, but line focused comments
>> are obviously also super good, so I've felt conflicted there.
>>
>>
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Wed, May 11, 2022 at 12:58 AM Tomoko Uchida <
>>> tomoko.uchida.1111@gmail.com> wrote:
>>>
>>>> Thanks everyone for your thoughtful comments - I think we can learn a
>>>> lot from Solr Operator project.
>>>>
>>>> And then, I'd appreciate the feedback from Julie; not only because of
>>>> the support for the migration but also because we surely need feedback from
>>>> committers/contributors who actively create or review patches/PRs on a
>>>> regular basis and drives this project like you.
>>>> Of course, advisory comments from the whole community are really
>>>> helpful and I welcome feedback from all developers, regardless of the
>>>> activities on Lucene.
>>>>
>>>> I don't think I'm good at facilitation, I'll try to be here though :)
>>>> I hope we'll continue a good conversation, and then, we can be
>>>> confident opening the official vote.
>>>>
>>>> Tomoko
>>>>
>>>>
>>>> 2022?5?11?(?) 9:36 Julie Tibshirani <julietibs@gmail.com>:
>>>>
>>>>> I don't have much to add to the (already very detailed!) discussion,
>>>>> just wanted to add my support for the idea of moving to GitHub. I've had a
>>>>> good experience with GitHub issues for other repos I contribute to and find
>>>>> the mark-up language comfortable and expressive. I also think switching to
>>>>> GitHub could help newer contributors engage with the project. When I first
>>>>> started contributing I found it really hard to navigate and search JIRA for
>>>>> issues I was interested in. Now I rely on Mike's wonderful JIRA search tool
>>>>> (https://jirasearch.mikemccandless.com/search.py), but most new
>>>>> contributors do not know about it (and it adds another dependency on top of
>>>>> GitHub and JIRA).
>>>>>
>>>>> Julie
>>>>>
>>>>> On Tue, May 10, 2022 at 12:41 PM Houston Putman <houston@apache.org>
>>>>> wrote:
>>>>>
>>>>>> I'm not going to get into how the Github automation should be done,
>>>>>> that's a whole separate thread. But I agree too much automation can
>>>>>> certainly be annoying and a burden. You can see this a lot in the
>>>>>> kubernetes repos (https://github.com/kubernetes), though it does
>>>>>> come with its reasons.
>>>>>>
>>>>>> Kubernetes is a good example of a project MUCH bigger than Solr
>>>>>> successfully using Github Issues & PRs. So I don't really think it's a
>>>>>> question if Github is feature-rich enough to handle our use case, it's
>>>>>> pretty clear that it is. It will certainly be a change in process, but I
>>>>>> think that all of these very successful open source projects show that it's
>>>>>> a valid option for our projects. I think the ultimate questions are:
>>>>>>
>>>>>> - Which will be easier for users to find relevant information?
>>>>>> - Which reduces the amount of bureaucracy needed to contribute to
>>>>>> the project?
>>>>>> - Which fits into the workflows of existing committers the best?
>>>>>>
>>>>>> To me Github comes up on top, even though there are things that JIRA
>>>>>> does better.
>>>>>>
>>>>>> P.S. I think you mean https://github.com/helm/charts, marcus. I
>>>>>> don't think helm is deprecated
>>>>>>
>>>>>> On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <marcuseagan@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I recommend people take a look at the now deprecated helm project.
>>>>>>> It was very difficult to land PRs because they had so much governance and
>>>>>>> automation. For a data store as mature as SOLR, I would suggest it is
>>>>>>> needed.
>>>>>>>
>>>>>>> Many issues are worth a read: https://github.com/helm/helm
>>>>>>>
>>>>>>> On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.heck@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <houston@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Most modern open source projects use Github Issues for their issue
>>>>>>>>> tracking, so it's definitely doable, and really what new
>>>>>>>>> users/contributors will be expecting. Also I see that much discussion is
>>>>>>>>> already done on PRs, and JIRAs are mainly there just for
>>>>>>>>> bureaucratic purposes. So I think it would be a wonderful direction to go
>>>>>>>>> in.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> On that note, many such projects I find it more difficult to get
>>>>>>>> clarity on whether or not I'm affected by the issue, or in what version it
>>>>>>>> was resolved. Usually i can be achieved by clicking on the referenced
>>>>>>>> commit, and then inspecting what tags are on that commit, but it's several
>>>>>>>> clicks and a minute or two vs just looking at the field in Jira...
>>>>>>>>
>>>>>>>> This can be made easier by using milestones as seen here (random
>>>>>>>> example, used gradle because it's a very large, healthy project):
>>>>>>>> https://github.com/gradle/gradle/issues/20182
>>>>>>>>
>>>>>>>> But I've seen a lot of projects that don't do that... which
>>>>>>>> probably colors my view a bit.
>>>>>>>>
>>>>>>>> -Gus
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://www.needhamsoftware.com (work)
>>>>>>>> http://www.the111shift.com (play)
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Marcus Eagan
>>>>>>>
>>>>>>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>