Mailing List Archive

1 2 3  View All
Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557) [ In reply to ]
Thank you Mike for your support and comment.

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

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

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

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

Tomoko


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

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

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


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

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


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

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557) [ In reply to ]
We have been having a very long discussion many issues are posed, thank you
everyone who is involved.
Here is a short, non-exhaustive summary of posed issues/questions (with my
brief thoughts/opinions) so far.

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

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

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

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

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

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

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

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

Tomoko


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

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

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

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

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

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

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

And I drafted an early migration plan on the issue.

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

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

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

Tomoko

Tomoko


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

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

1 2 3  View All