Mailing List Archive

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
>>>>
>>>>