Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Tomoko Uchida]

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 :

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


 On Tue, May 10, 2022 at 10:40 AM Houston Putman 
 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)

[Julie Tibshirani]

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  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 
> 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  wrote:
>>
>>>
>>>
>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman 
>>> 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)

[Houston Putman]

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  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  wrote:
>
>>
>>
>> On Tue, May 10, 2022 at 10:40 AM Houston Putman 
>> 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)

[Marcus Eagan]

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

>
>
> On Tue, May 10, 2022 at 10:40 AM Houston Putman 
> 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)

[Gus Heck]

On Tue, May 10, 2022 at 10:40 AM Houston Putman  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)

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Gus Heck]

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  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.1...@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 :
>>
>>> 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

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Houston Putman]

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

Re: Lucene 9.2 release

[Alan Woodward]

Hi Mayya,

Yes, that’s fine.  I will hold off until you have merged those two PRs.

- Alan

> On 10 May 2022, at 14:24, Mayya Sharipova  > wrote:
> 
> Hi Alan,
> we have PRs (870 , 872 
> ) in progress that involve format 
> changes to vectors. We would like to merge them for 9.2.
> Would it be possible to wait for a couple of days for the branch cut? I can 
> update here once these PRs are merged.
> 
> Thank you in advance
> 
> On Wed, May 4, 2022 at 2:59 AM Tomoko Uchida  > wrote:
> +1
> 
> Thank you Alan!
> 
> I wonder if it makes sense to include in the highlighted updates that pull 
> requests to the github repository no longer require Jira issues?
> I'm trying to adjust the contribution workflow more GitHub-oriented and there 
> is a related issue https://issues.apache.org/jira/browse/LUCENE-10543 
> , an announcement could 
> be helpful to proceed with it (if it gains basic agreement among committers). 
> 
> Tomoko
> 
> 
> 2022年5月4日(水) 2:26 Ignacio Vera mailto:iver...@gmail.com>>:
> +1 
> 
> Thanks Alan!
> 
> > On 3. May 2022, at 13:01, Alan Woodward  > > wrote:
> > 
> > Hi all,
> > 
> > It’s been six weeks or so since we released 9.1, and we have a bunch of 
> > nice new features and enhancements piling up in the 9.x branch.  I’d like 
> > to volunteer to be a release manager for a 9.2 release.  I propose to cut a 
> > branch this time next week, 10th May.
> > 
> > - Alan
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > 
> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > 
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 

Re: Lucene 9.2 release

[Mayya Sharipova]

Hi Alan,
we have PRs (870 , 872
) in progress that involve
format changes to vectors. We would like to merge them for 9.2.
Would it be possible to wait for a couple of days for the branch cut? I can
update here once these PRs are merged.

Thank you in advance

On Wed, May 4, 2022 at 2:59 AM Tomoko Uchida 
wrote:

> +1
>
> Thank you Alan!
>
> I wonder if it makes sense to include in the highlighted updates that pull
> requests to the github repository no longer require Jira issues?
> I'm trying to adjust the contribution workflow more GitHub-oriented and
> there is a related issue
> https://issues.apache.org/jira/browse/LUCENE-10543, an announcement could
> be helpful to proceed with it (if it gains basic agreement among
> committers).
>
> Tomoko
>
>
> 2022年5月4日(水) 2:26 Ignacio Vera :
>
>> +1
>>
>> Thanks Alan!
>>
>> > On 3. May 2022, at 13:01, Alan Woodward  wrote:
>> >
>> > Hi all,
>> >
>> > It’s been six weeks or so since we released 9.1, and we have a bunch of
>> nice new features and enhancements piling up in the 9.x branch.  I’d like
>> to volunteer to be a release manager for a 9.2 release.  I propose to cut a
>> branch this time next week, 10th May.
>> >
>> > - Alan
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Tomoko Uchida]

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 :

> 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 
> LinkedIn  | Twitter
>  | Youtube
>  | Github
> 
>
>
> On Tue, 10 May 2022 at 06:04, Tomoko Uchida 
> 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 

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Alessandro Benedetti]

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 
LinkedIn  | Twitter
 | Youtube
 | Github



On Tue, 10 May 2022 at 06:04, Tomoko Uchida 
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 :
>
>> 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 :
>>
>>> On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida
>>>  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