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.benede...@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.benede...@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.1...@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.1...@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 <rcm...@gmail.com>: >>> >>>> On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida >>>> <tomoko.uchida.1...@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-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>>>
