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.h...@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.1...@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 <juliet...@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 <hous...@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 <marcusea...@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.h...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <hous...@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)
>
