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 <[email protected]> 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 < > [email protected]> 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 <[email protected]>: >> >>> 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: [email protected] >>> >>> >>> *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 < >>> [email protected]> 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 <[email protected]>: >>>> >>>>> 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 <[email protected]>: >>>>> >>>>>> On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida >>>>>> <[email protected]> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
