Notes from the committers' meeting at Activate 2019

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Notes from the committers' meeting at Activate 2019

Andrzej Białecki-2
Hey folks,

Some of the committers attended the Activate 2019 conference, which took place in Washington, DC on Sep 10-13.

The schedule was packed, so we managed to only have a ~1hr meeting during a lunch break - nonetheless, I think it was still very productive!

Committers attending (at least some part of) the meeting, in no particular order: Erik Hatcher, Anshum Gupta, David Smiley, Gus Heck, Noble Paul, Varun Thacker, Ishan Chattopadhyaya, Tomás Löbbe, and yours truly.

Here are the notes I took - those attending, feel free to clear up any errors, omissions or misunderstandings.

- Clean up tests that needlessly use AbstractDistribZk…
    - because this class creates a control collection, which in many cases is not needed.

- Consider reusing a single MiniSolrCloudCluster instance for multiple test suites
    - always use unique collection names per suite / test
    - some suites won’t be able to use this due to a particular setup or side-effects (sysprops, expected metrics, etc)
    - those that can should execute much faster

- Deprecations in 8x - we still need to actually remove the stuff from master:
    - old blob store
    - old spatial
    - other things?

- Replace NamedList with MapWriter?
    - avoid creating objects during serialization
    - big undertaking, but transition piece by piece
    - example: ExportHandler / ExportWriter
    - new API should use MapWriter instead of NamedList / Map
    - public API changes have to go through deprecation in 8x and removal only in 9

- We have three different and partially incomplete faceting impls
    - do we want to do something about it to reduce confusion and code footprint?

- V2 APIs are incomplete, there’s no workflow to maintain them in sync with v1. Proposed strategy to improve this:
    - move SolrJ to v2 - this could be done soon
    - move Solr internally to use v2
    - move tests to use v2 by default.
    - RefGuide in 9.0 should show v2 examples by default
    - deprecate v1
    - come up with a better way of creating v2 api metadata (annotations?)

- Promote GitHub-centric approach to dev & collaboration
    - PRs as the main method for submitting contributions
    - How to Contribute should be the first section of the github page
    - PR is opened - should automatically create a jira if it doesn’t exist yet
    - discourage using patches when code review is expected.
    - PR is more inviting for collaboration than a patch
    - downside: PR is only for a single branch (no backport integration)
    - travis integration?
    - or use Github Actions for automated precommits, tests

- Javadocs, typos, small ref guide changes should not require a Jira issue with its overheads

—--

Andrzej Białecki


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Ishan Chattopadhyaya
> Committers attending (at least some part of) the meeting, in no particular order: Erik Hatcher, Anshum Gupta, David Smiley, Gus Heck, Noble Paul, Varun Thacker, Ishan Chattopadhyaya, Tomás Löbbe, and yours truly.

Also, Tim Allison, Joel Bernstein, Jason Gerlowski. (Did we miss out
someone else too?)

On Mon, Sep 16, 2019 at 7:24 AM Andrzej Białecki <[hidden email]> wrote:

>
> Hey folks,
>
> Some of the committers attended the Activate 2019 conference, which took place in Washington, DC on Sep 10-13.
>
> The schedule was packed, so we managed to only have a ~1hr meeting during a lunch break - nonetheless, I think it was still very productive!
>
> Committers attending (at least some part of) the meeting, in no particular order: Erik Hatcher, Anshum Gupta, David Smiley, Gus Heck, Noble Paul, Varun Thacker, Ishan Chattopadhyaya, Tomás Löbbe, and yours truly.
>
> Here are the notes I took - those attending, feel free to clear up any errors, omissions or misunderstandings.
>
> - Clean up tests that needlessly use AbstractDistribZk…
>     - because this class creates a control collection, which in many cases is not needed.
>
> - Consider reusing a single MiniSolrCloudCluster instance for multiple test suites
>     - always use unique collection names per suite / test
>     - some suites won’t be able to use this due to a particular setup or side-effects (sysprops, expected metrics, etc)
>     - those that can should execute much faster
>
> - Deprecations in 8x - we still need to actually remove the stuff from master:
>     - old blob store
>     - old spatial
>     - other things?
>
> - Replace NamedList with MapWriter?
>     - avoid creating objects during serialization
>     - big undertaking, but transition piece by piece
>     - example: ExportHandler / ExportWriter
>     - new API should use MapWriter instead of NamedList / Map
>     - public API changes have to go through deprecation in 8x and removal only in 9
>
> - We have three different and partially incomplete faceting impls
>     - do we want to do something about it to reduce confusion and code footprint?
>
> - V2 APIs are incomplete, there’s no workflow to maintain them in sync with v1. Proposed strategy to improve this:
>     - move SolrJ to v2 - this could be done soon
>     - move Solr internally to use v2
>     - move tests to use v2 by default.
>     - RefGuide in 9.0 should show v2 examples by default
>     - deprecate v1
>     - come up with a better way of creating v2 api metadata (annotations?)
>
> - Promote GitHub-centric approach to dev & collaboration
>     - PRs as the main method for submitting contributions
>     - How to Contribute should be the first section of the github page
>     - PR is opened - should automatically create a jira if it doesn’t exist yet
>     - discourage using patches when code review is expected.
>     - PR is more inviting for collaboration than a patch
>     - downside: PR is only for a single branch (no backport integration)
>     - travis integration?
>     - or use Github Actions for automated precommits, tests
>
> - Javadocs, typos, small ref guide changes should not require a Jira issue with its overheads
>
> —--
>
> Andrzej Białecki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Andrzej Białecki-2


> On 16 Sep 2019, at 17:55, Ishan Chattopadhyaya <[hidden email]> wrote:
>
>> Committers attending (at least some part of) the meeting, in no particular order: Erik Hatcher, Anshum Gupta, David Smiley, Gus Heck, Noble Paul, Varun Thacker, Ishan Chattopadhyaya, Tomás Löbbe, and yours truly.
>
> Also, Tim Allison, Joel Bernstein, Jason Gerlowski. (Did we miss out
> someone else too?)

Gah, of course, sorry guys - I was even sitting next to them…

>
> On Mon, Sep 16, 2019 at 7:24 AM Andrzej Białecki <[hidden email]> wrote:
>>
>> Hey folks,
>>
>> Some of the committers attended the Activate 2019 conference, which took place in Washington, DC on Sep 10-13.
>>
>> The schedule was packed, so we managed to only have a ~1hr meeting during a lunch break - nonetheless, I think it was still very productive!
>>
>> Committers attending (at least some part of) the meeting, in no particular order: Erik Hatcher, Anshum Gupta, David Smiley, Gus Heck, Noble Paul, Varun Thacker, Ishan Chattopadhyaya, Tomás Löbbe, and yours truly.
>>
>> Here are the notes I took - those attending, feel free to clear up any errors, omissions or misunderstandings.
>>
>> - Clean up tests that needlessly use AbstractDistribZk…
>>    - because this class creates a control collection, which in many cases is not needed.
>>
>> - Consider reusing a single MiniSolrCloudCluster instance for multiple test suites
>>    - always use unique collection names per suite / test
>>    - some suites won’t be able to use this due to a particular setup or side-effects (sysprops, expected metrics, etc)
>>    - those that can should execute much faster
>>
>> - Deprecations in 8x - we still need to actually remove the stuff from master:
>>    - old blob store
>>    - old spatial
>>    - other things?
>>
>> - Replace NamedList with MapWriter?
>>    - avoid creating objects during serialization
>>    - big undertaking, but transition piece by piece
>>    - example: ExportHandler / ExportWriter
>>    - new API should use MapWriter instead of NamedList / Map
>>    - public API changes have to go through deprecation in 8x and removal only in 9
>>
>> - We have three different and partially incomplete faceting impls
>>    - do we want to do something about it to reduce confusion and code footprint?
>>
>> - V2 APIs are incomplete, there’s no workflow to maintain them in sync with v1. Proposed strategy to improve this:
>>    - move SolrJ to v2 - this could be done soon
>>    - move Solr internally to use v2
>>    - move tests to use v2 by default.
>>    - RefGuide in 9.0 should show v2 examples by default
>>    - deprecate v1
>>    - come up with a better way of creating v2 api metadata (annotations?)
>>
>> - Promote GitHub-centric approach to dev & collaboration
>>    - PRs as the main method for submitting contributions
>>    - How to Contribute should be the first section of the github page
>>    - PR is opened - should automatically create a jira if it doesn’t exist yet
>>    - discourage using patches when code review is expected.
>>    - PR is more inviting for collaboration than a patch
>>    - downside: PR is only for a single branch (no backport integration)
>>    - travis integration?
>>    - or use Github Actions for automated precommits, tests
>>
>> - Javadocs, typos, small ref guide changes should not require a Jira issue with its overheads
>>
>> —--
>>
>> Andrzej Białecki
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Yonik Seeley
In reply to this post by Andrzej Białecki-2
>  - PR is opened - should automatically create a jira if it doesn’t exist yet

What were the reasons behind this? Shouldn't a JIRA just be optional if we started with a PR?

-Yonik

Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Andrzej Białecki-2

On 16 Sep 2019, at 19:38, Yonik Seeley <[hidden email]> wrote:

>  - PR is opened - should automatically create a jira if it doesn’t exist yet

What were the reasons behind this? Shouldn't a JIRA just be optional if we started with a PR?

That’s why we need to discuss this :)

I remember that at some point ASF treated JIRA as the system of record for the legal validation of contributions.

I also remember that at some point we used to say that if a discussion didn’t happen in JIRA then it didn’t exist, and that any decisions regarding code should be recorded in JIRA because we can’t expect people to monitor and contribute / object to decisions happening elsewhere.


Andrzej Białecki

Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Jan Høydahl / Cominvent
Is there any reason at all that we need to hold on to JIRA? ASF allows us to move all issue handling over to GH, I'd like us to consider such a move.

Until then, I made a script that "diffs" GH and JIRA and outputs a report, see https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy

Running the tool shows that we're not very successful in keeping the two in sync, we also forget to close PRs after JIRAs are resolved:

$ ./githubPRs.py 
Lucene/Solr Github PR report
============================
Number of open Pull Requests: 208

PRs lacking JIRA reference in title
  #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
  #880: Tweak header format.
  [… many more ]

Open PRs with a resolved JIRA
  #723: SOLR-13545 status=Closed, resolution=Fixed, resolutiondate=2019-06-22T13:04:47.000+0000 (SOLR-13545: AutoClose stream in ContentStreamUpdateRequest)
  #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
  [… many more]

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <[hidden email]>:


On 16 Sep 2019, at 19:38, Yonik Seeley <[hidden email]> wrote:

>  - PR is opened - should automatically create a jira if it doesn’t exist yet

What were the reasons behind this? Shouldn't a JIRA just be optional if we started with a PR?

That’s why we need to discuss this :)

I remember that at some point ASF treated JIRA as the system of record for the legal validation of contributions.

I also remember that at some point we used to say that if a discussion didn’t happen in JIRA then it didn’t exist, and that any decisions regarding code should be recorded in JIRA because we can’t expect people to monitor and contribute / object to decisions happening elsewhere.


Andrzej Białecki


Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Gus Heck
FWIW, One thing that needs to be figured out is how github would accommodate security issues (or how the process for those issues would change).  Does github have the ability to assign roles and visibility (could be I haven't really worked with organizations on GitHub, all my clients have been on jira ... except the one that has trello, and another with gitlab... neither of which have impressed me very much )?

Additionally, I'm slightly leery of the move since I don't (yet) see the real benefit that pays for the splitting of the records into two systems. Can issues be migrated to github? I've not really been on a large project that used only GitHub, can someone explain what we *gain* by moving to GitHub issues. At least two things are lost: continuity and familiarity. My impression is that there are a lot fewer features, but maybe I've just not been exposed to them. 

Part of me worries that this is the usual cycle of "this is simpler" (mass migration ensues) "but it doesn't x, y and z" (x, y and z are added) "wow this is complex, but THAT is simpler...." (mass migration ensues...) "hmm p, q an z are missing" (p q and z are added  and cycle repeats). So I'm skeptical of any "gain" hanging it's hat solely on "simplicity". Jira used to be the simpler, snazzier, sexier alternative to bugzilla...

Sell me, I'm all ears, but not seeing it yet :)

-Gus

On Mon, Sep 16, 2019 at 3:57 PM Jan Høydahl <[hidden email]> wrote:
Is there any reason at all that we need to hold on to JIRA? ASF allows us to move all issue handling over to GH, I'd like us to consider such a move.

Until then, I made a script that "diffs" GH and JIRA and outputs a report, see https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy

Running the tool shows that we're not very successful in keeping the two in sync, we also forget to close PRs after JIRAs are resolved:

$ ./githubPRs.py 
Lucene/Solr Github PR report
============================
Number of open Pull Requests: 208

PRs lacking JIRA reference in title
  #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
  #880: Tweak header format.
  [… many more ]

Open PRs with a resolved JIRA
  #723: SOLR-13545 status=Closed, resolution=Fixed, resolutiondate=2019-06-22T13:04:47.000+0000 (SOLR-13545: AutoClose stream in ContentStreamUpdateRequest)
  #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
  [… many more]

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <[hidden email]>:


On 16 Sep 2019, at 19:38, Yonik Seeley <[hidden email]> wrote:

>  - PR is opened - should automatically create a jira if it doesn’t exist yet

What were the reasons behind this? Shouldn't a JIRA just be optional if we started with a PR?

That’s why we need to discuss this :)

I remember that at some point ASF treated JIRA as the system of record for the legal validation of contributions.

I also remember that at some point we used to say that if a discussion didn’t happen in JIRA then it didn’t exist, and that any decisions regarding code should be recorded in JIRA because we can’t expect people to monitor and contribute / object to decisions happening elsewhere.


Andrzej Białecki




--
Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

david.w.smiley@gmail.com
+1 to all that Gus said.  On a fresh project then indeed perhaps we would use GitHub issues but it's not nearly so compelling at this point with so much rich history in JIRA, not to mention those issues being referenced in commit messages.

Is the point to lower barriers for contributors that are not in our community yet (thus don't have an ASF JIRA account)?  Well... they don't *have* to create the JIRA issue if a committer is sufficiently interested in the issue at hand to do it.  And as mentioned this could be automated.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <[hidden email]> wrote:
FWIW, One thing that needs to be figured out is how github would accommodate security issues (or how the process for those issues would change).  Does github have the ability to assign roles and visibility (could be I haven't really worked with organizations on GitHub, all my clients have been on jira ... except the one that has trello, and another with gitlab... neither of which have impressed me very much )?

Additionally, I'm slightly leery of the move since I don't (yet) see the real benefit that pays for the splitting of the records into two systems. Can issues be migrated to github? I've not really been on a large project that used only GitHub, can someone explain what we *gain* by moving to GitHub issues. At least two things are lost: continuity and familiarity. My impression is that there are a lot fewer features, but maybe I've just not been exposed to them. 

Part of me worries that this is the usual cycle of "this is simpler" (mass migration ensues) "but it doesn't x, y and z" (x, y and z are added) "wow this is complex, but THAT is simpler...." (mass migration ensues...) "hmm p, q an z are missing" (p q and z are added  and cycle repeats). So I'm skeptical of any "gain" hanging it's hat solely on "simplicity". Jira used to be the simpler, snazzier, sexier alternative to bugzilla...

Sell me, I'm all ears, but not seeing it yet :)

-Gus

On Mon, Sep 16, 2019 at 3:57 PM Jan Høydahl <[hidden email]> wrote:
Is there any reason at all that we need to hold on to JIRA? ASF allows us to move all issue handling over to GH, I'd like us to consider such a move.

Until then, I made a script that "diffs" GH and JIRA and outputs a report, see https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy

Running the tool shows that we're not very successful in keeping the two in sync, we also forget to close PRs after JIRAs are resolved:

$ ./githubPRs.py 
Lucene/Solr Github PR report
============================
Number of open Pull Requests: 208

PRs lacking JIRA reference in title
  #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
  #880: Tweak header format.
  [… many more ]

Open PRs with a resolved JIRA
  #723: SOLR-13545 status=Closed, resolution=Fixed, resolutiondate=2019-06-22T13:04:47.000+0000 (SOLR-13545: AutoClose stream in ContentStreamUpdateRequest)
  #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
  [… many more]

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <[hidden email]>:


On 16 Sep 2019, at 19:38, Yonik Seeley <[hidden email]> wrote:

>  - PR is opened - should automatically create a jira if it doesn’t exist yet

What were the reasons behind this? Shouldn't a JIRA just be optional if we started with a PR?

That’s why we need to discuss this :)

I remember that at some point ASF treated JIRA as the system of record for the legal validation of contributions.

I also remember that at some point we used to say that if a discussion didn’t happen in JIRA then it didn’t exist, and that any decisions regarding code should be recorded in JIRA because we can’t expect people to monitor and contribute / object to decisions happening elsewhere.


Andrzej Białecki




--
Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Eric Pugh-4
Ah..   The mythical committer just sitting around waiting to be “interested in the issue” that you have created!   Having said that, I think thats a separate challenge!


On Sep 17, 2019, at 12:38 AM, David Smiley <[hidden email]> wrote:

+1 to all that Gus said.  On a fresh project then indeed perhaps we would use GitHub issues but it's not nearly so compelling at this point with so much rich history in JIRA, not to mention those issues being referenced in commit messages.

Is the point to lower barriers for contributors that are not in our community yet (thus don't have an ASF JIRA account)?  Well... they don't *have* to create the JIRA issue if a committer is sufficiently interested in the issue at hand to do it.  And as mentioned this could be automated.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <[hidden email]> wrote:
FWIW, One thing that needs to be figured out is how github would accommodate security issues (or how the process for those issues would change).  Does github have the ability to assign roles and visibility (could be I haven't really worked with organizations on GitHub, all my clients have been on jira ... except the one that has trello, and another with gitlab... neither of which have impressed me very much )?

Additionally, I'm slightly leery of the move since I don't (yet) see the real benefit that pays for the splitting of the records into two systems. Can issues be migrated to github? I've not really been on a large project that used only GitHub, can someone explain what we *gain* by moving to GitHub issues. At least two things are lost: continuity and familiarity. My impression is that there are a lot fewer features, but maybe I've just not been exposed to them. 

Part of me worries that this is the usual cycle of "this is simpler" (mass migration ensues) "but it doesn't x, y and z" (x, y and z are added) "wow this is complex, but THAT is simpler...." (mass migration ensues...) "hmm p, q an z are missing" (p q and z are added  and cycle repeats). So I'm skeptical of any "gain" hanging it's hat solely on "simplicity". Jira used to be the simpler, snazzier, sexier alternative to bugzilla...

Sell me, I'm all ears, but not seeing it yet :)

-Gus

On Mon, Sep 16, 2019 at 3:57 PM Jan Høydahl <[hidden email]> wrote:
Is there any reason at all that we need to hold on to JIRA? ASF allows us to move all issue handling over to GH, I'd like us to consider such a move.

Until then, I made a script that "diffs" GH and JIRA and outputs a report, see https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy

Running the tool shows that we're not very successful in keeping the two in sync, we also forget to close PRs after JIRAs are resolved:

$ ./githubPRs.py 
Lucene/Solr Github PR report
============================
Number of open Pull Requests: 208

PRs lacking JIRA reference in title
  #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
  #880: Tweak header format.
  [… many more ]

Open PRs with a resolved JIRA
  #723: SOLR-13545 status=Closed, resolution=Fixed, resolutiondate=2019-06-22T13:04:47.000+0000 (SOLR-13545: AutoClose stream in ContentStreamUpdateRequest)
  #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
  [… many more]

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <[hidden email]>:


On 16 Sep 2019, at 19:38, Yonik Seeley <[hidden email]> wrote:

>  - PR is opened - should automatically create a jira if it doesn’t exist yet

What were the reasons behind this? Shouldn't a JIRA just be optional if we started with a PR?

That’s why we need to discuss this :)

I remember that at some point ASF treated JIRA as the system of record for the legal validation of contributions.

I also remember that at some point we used to say that if a discussion didn’t happen in JIRA then it didn’t exist, and that any decisions regarding code should be recorded in JIRA because we can’t expect people to monitor and contribute / object to decisions happening elsewhere.


Andrzej Białecki




--

_______________________
Eric Pugh Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy  
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.

Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Jason Gerlowski
I missed the part of the meeting/lunch when our use of Github came up.
Can anyone that was present summarize the discussion in a little more
detail?

re: issues on github.  There are challenges like avoiding
fragmentation and keeping multiple issue sources up to date, but those
are problems that probably shrink or go away with appropriate
automation.  IMO at least, issue reporting is largely the same whether
you're on Github, JIRA, trello, etc.  You fill out a form, set the
appropriate tags and fields, etc.  I'm fine w/ changes there, but it's
hard for me to imagine how that would have much/any impact on barrier
to entry.

I see our code-contribution process as a much bigger driver of the
barrier-to-entry. First time contributors must learn how to generate
patches.  They receive code-review on JIRA, so they get one chunk of
text in a comment.  And contributions have very weak version control
(identically named SOLR-####.patch files piling up on the same issue).
Github has concrete benefits here.  If the goal is to make it easier
for contributors to get involved, making Github first-class for code
contributions might be where the real gains are.  (We allow Github
PR's, but could steer people towards them more clearly: rewrite
HowToContribute docs to assume Github, hide the patch process for new
contributors, set up workflows in Github to run precommit/tests on
PRs, etc.)

On Tue, Sep 17, 2019 at 8:56 AM Eric Pugh
<[hidden email]> wrote:

>
> Ah..   The mythical committer just sitting around waiting to be “interested in the issue” that you have created!   Having said that, I think thats a separate challenge!
>
>
> On Sep 17, 2019, at 12:38 AM, David Smiley <[hidden email]> wrote:
>
> +1 to all that Gus said.  On a fresh project then indeed perhaps we would use GitHub issues but it's not nearly so compelling at this point with so much rich history in JIRA, not to mention those issues being referenced in commit messages.
>
> Is the point to lower barriers for contributors that are not in our community yet (thus don't have an ASF JIRA account)?  Well... they don't *have* to create the JIRA issue if a committer is sufficiently interested in the issue at hand to do it.  And as mentioned this could be automated.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <[hidden email]> wrote:
>>
>> FWIW, One thing that needs to be figured out is how github would accommodate security issues (or how the process for those issues would change).  Does github have the ability to assign roles and visibility (could be I haven't really worked with organizations on GitHub, all my clients have been on jira ... except the one that has trello, and another with gitlab... neither of which have impressed me very much )?
>>
>> Additionally, I'm slightly leery of the move since I don't (yet) see the real benefit that pays for the splitting of the records into two systems. Can issues be migrated to github? I've not really been on a large project that used only GitHub, can someone explain what we *gain* by moving to GitHub issues. At least two things are lost: continuity and familiarity. My impression is that there are a lot fewer features, but maybe I've just not been exposed to them.
>>
>> Part of me worries that this is the usual cycle of "this is simpler" (mass migration ensues) "but it doesn't x, y and z" (x, y and z are added) "wow this is complex, but THAT is simpler...." (mass migration ensues...) "hmm p, q an z are missing" (p q and z are added  and cycle repeats). So I'm skeptical of any "gain" hanging it's hat solely on "simplicity". Jira used to be the simpler, snazzier, sexier alternative to bugzilla...
>>
>> Sell me, I'm all ears, but not seeing it yet :)
>>
>> -Gus
>>
>> On Mon, Sep 16, 2019 at 3:57 PM Jan Høydahl <[hidden email]> wrote:
>>>
>>> Is there any reason at all that we need to hold on to JIRA? ASF allows us to move all issue handling over to GH, I'd like us to consider such a move.
>>>
>>> Until then, I made a script that "diffs" GH and JIRA and outputs a report, see https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy
>>>
>>> Running the tool shows that we're not very successful in keeping the two in sync, we also forget to close PRs after JIRAs are resolved:
>>>
>>> $ ./githubPRs.py
>>> Lucene/Solr Github PR report
>>> ============================
>>> Number of open Pull Requests: 208
>>>
>>> PRs lacking JIRA reference in title
>>>   #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
>>>   #880: Tweak header format.
>>>   [… many more ]
>>>
>>> Open PRs with a resolved JIRA
>>>   #723: SOLR-13545 status=Closed, resolution=Fixed, resolutiondate=2019-06-22T13:04:47.000+0000 (SOLR-13545: AutoClose stream in ContentStreamUpdateRequest)
>>>   #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
>>>   [… many more]
>>>
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>>
>>> 16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <[hidden email]>:
>>>
>>>
>>> On 16 Sep 2019, at 19:38, Yonik Seeley <[hidden email]> wrote:
>>>
>>> >  - PR is opened - should automatically create a jira if it doesn’t exist yet
>>>
>>> What were the reasons behind this? Shouldn't a JIRA just be optional if we started with a PR?
>>>
>>>
>>> That’s why we need to discuss this :)
>>>
>>> I remember that at some point ASF treated JIRA as the system of record for the legal validation of contributions.
>>>
>>> I also remember that at some point we used to say that if a discussion didn’t happen in JIRA then it didn’t exist, and that any decisions regarding code should be recorded in JIRA because we can’t expect people to monitor and contribute / object to decisions happening elsewhere.
>>>
>>> —
>>>
>>> Andrzej Białecki
>>>
>>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>
> _______________________
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

david.w.smiley@gmail.com
Well put Jason.  I think we didn't discuss it in any further detail than what you said right here -- basically cater to GitHub PRs and either discourage or undocument "patch file" based contributions.  That's it in a sentence.  We all nodded our head to that, albeit some of us like me confess to enjoying the ease of patch based contributions.

~ David Smiley
Apache Lucene/Solr Search Developer


On Tue, Sep 17, 2019 at 9:46 AM Jason Gerlowski <[hidden email]> wrote:
I missed the part of the meeting/lunch when our use of Github came up.
Can anyone that was present summarize the discussion in a little more
detail?

re: issues on github.  There are challenges like avoiding
fragmentation and keeping multiple issue sources up to date, but those
are problems that probably shrink or go away with appropriate
automation.  IMO at least, issue reporting is largely the same whether
you're on Github, JIRA, trello, etc.  You fill out a form, set the
appropriate tags and fields, etc.  I'm fine w/ changes there, but it's
hard for me to imagine how that would have much/any impact on barrier
to entry.

I see our code-contribution process as a much bigger driver of the
barrier-to-entry. First time contributors must learn how to generate
patches.  They receive code-review on JIRA, so they get one chunk of
text in a comment.  And contributions have very weak version control
(identically named SOLR-####.patch files piling up on the same issue).
Github has concrete benefits here.  If the goal is to make it easier
for contributors to get involved, making Github first-class for code
contributions might be where the real gains are.  (We allow Github
PR's, but could steer people towards them more clearly: rewrite
HowToContribute docs to assume Github, hide the patch process for new
contributors, set up workflows in Github to run precommit/tests on
PRs, etc.)

On Tue, Sep 17, 2019 at 8:56 AM Eric Pugh
<[hidden email]> wrote:
>
> Ah..   The mythical committer just sitting around waiting to be “interested in the issue” that you have created!   Having said that, I think thats a separate challenge!
>
>
> On Sep 17, 2019, at 12:38 AM, David Smiley <[hidden email]> wrote:
>
> +1 to all that Gus said.  On a fresh project then indeed perhaps we would use GitHub issues but it's not nearly so compelling at this point with so much rich history in JIRA, not to mention those issues being referenced in commit messages.
>
> Is the point to lower barriers for contributors that are not in our community yet (thus don't have an ASF JIRA account)?  Well... they don't *have* to create the JIRA issue if a committer is sufficiently interested in the issue at hand to do it.  And as mentioned this could be automated.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <[hidden email]> wrote:
>>
>> FWIW, One thing that needs to be figured out is how github would accommodate security issues (or how the process for those issues would change).  Does github have the ability to assign roles and visibility (could be I haven't really worked with organizations on GitHub, all my clients have been on jira ... except the one that has trello, and another with gitlab... neither of which have impressed me very much )?
>>
>> Additionally, I'm slightly leery of the move since I don't (yet) see the real benefit that pays for the splitting of the records into two systems. Can issues be migrated to github? I've not really been on a large project that used only GitHub, can someone explain what we *gain* by moving to GitHub issues. At least two things are lost: continuity and familiarity. My impression is that there are a lot fewer features, but maybe I've just not been exposed to them.
>>
>> Part of me worries that this is the usual cycle of "this is simpler" (mass migration ensues) "but it doesn't x, y and z" (x, y and z are added) "wow this is complex, but THAT is simpler...." (mass migration ensues...) "hmm p, q an z are missing" (p q and z are added  and cycle repeats). So I'm skeptical of any "gain" hanging it's hat solely on "simplicity". Jira used to be the simpler, snazzier, sexier alternative to bugzilla...
>>
>> Sell me, I'm all ears, but not seeing it yet :)
>>
>> -Gus
>>
>> On Mon, Sep 16, 2019 at 3:57 PM Jan Høydahl <[hidden email]> wrote:
>>>
>>> Is there any reason at all that we need to hold on to JIRA? ASF allows us to move all issue handling over to GH, I'd like us to consider such a move.
>>>
>>> Until then, I made a script that "diffs" GH and JIRA and outputs a report, see https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy
>>>
>>> Running the tool shows that we're not very successful in keeping the two in sync, we also forget to close PRs after JIRAs are resolved:
>>>
>>> $ ./githubPRs.py
>>> Lucene/Solr Github PR report
>>> ============================
>>> Number of open Pull Requests: 208
>>>
>>> PRs lacking JIRA reference in title
>>>   #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
>>>   #880: Tweak header format.
>>>   [… many more ]
>>>
>>> Open PRs with a resolved JIRA
>>>   #723: SOLR-13545 status=Closed, resolution=Fixed, resolutiondate=2019-06-22T13:04:47.000+0000 (SOLR-13545: AutoClose stream in ContentStreamUpdateRequest)
>>>   #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
>>>   [… many more]
>>>
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>>
>>> 16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <[hidden email]>:
>>>
>>>
>>> On 16 Sep 2019, at 19:38, Yonik Seeley <[hidden email]> wrote:
>>>
>>> >  - PR is opened - should automatically create a jira if it doesn’t exist yet
>>>
>>> What were the reasons behind this? Shouldn't a JIRA just be optional if we started with a PR?
>>>
>>>
>>> That’s why we need to discuss this :)
>>>
>>> I remember that at some point ASF treated JIRA as the system of record for the legal validation of contributions.
>>>
>>> I also remember that at some point we used to say that if a discussion didn’t happen in JIRA then it didn’t exist, and that any decisions regarding code should be recorded in JIRA because we can’t expect people to monitor and contribute / object to decisions happening elsewhere.
>>>
>>> —
>>>
>>> Andrzej Białecki
>>>
>>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>
> _______________________
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Mark Miller-3
I think I may prefer JIRA to GitHub Issues. I'm not sure.

Anyway, it's worth wondering if we can just move JIRA to GitHub. GitHub is now a first class mirror for Apache that we can commit to, but they still keep a primary copy of our code at Apache. Perhaps that is only a code concern now though.


As far as the GitHub vs patch issue, I don't want tell everyone they can't use patches, I usually prefer them, but, if we pushed everything through GitHub we can take super advantage of their free and way nicer than what we will ever have at Apache, Actions CI stuff. I'm not saying that will drive unit tests now or something, but for things like precommit and other checks (beasting on new tests or whatever), everyone going through that would be great. Would be awesome to project ourselves well in front of prs, or end up using the 2 branches and promoting changes when they are checked more thoroughly.

If we started using Git primarily that way, not using issues is probably more friction than we need ...

Mark

On Tue, Sep 17, 2019 at 2:46 PM David Smiley <[hidden email]> wrote:
Well put Jason.  I think we didn't discuss it in any further detail than what you said right here -- basically cater to GitHub PRs and either discourage or undocument "patch file" based contributions.  That's it in a sentence.  We all nodded our head to that, albeit some of us like me confess to enjoying the ease of patch based contributions.

~ David Smiley
Apache Lucene/Solr Search Developer


On Tue, Sep 17, 2019 at 9:46 AM Jason Gerlowski <[hidden email]> wrote:
I missed the part of the meeting/lunch when our use of Github came up.
Can anyone that was present summarize the discussion in a little more
detail?

re: issues on github.  There are challenges like avoiding
fragmentation and keeping multiple issue sources up to date, but those
are problems that probably shrink or go away with appropriate
automation.  IMO at least, issue reporting is largely the same whether
you're on Github, JIRA, trello, etc.  You fill out a form, set the
appropriate tags and fields, etc.  I'm fine w/ changes there, but it's
hard for me to imagine how that would have much/any impact on barrier
to entry.

I see our code-contribution process as a much bigger driver of the
barrier-to-entry. First time contributors must learn how to generate
patches.  They receive code-review on JIRA, so they get one chunk of
text in a comment.  And contributions have very weak version control
(identically named SOLR-####.patch files piling up on the same issue).
Github has concrete benefits here.  If the goal is to make it easier
for contributors to get involved, making Github first-class for code
contributions might be where the real gains are.  (We allow Github
PR's, but could steer people towards them more clearly: rewrite
HowToContribute docs to assume Github, hide the patch process for new
contributors, set up workflows in Github to run precommit/tests on
PRs, etc.)

On Tue, Sep 17, 2019 at 8:56 AM Eric Pugh
<[hidden email]> wrote:
>
> Ah..   The mythical committer just sitting around waiting to be “interested in the issue” that you have created!   Having said that, I think thats a separate challenge!
>
>
> On Sep 17, 2019, at 12:38 AM, David Smiley <[hidden email]> wrote:
>
> +1 to all that Gus said.  On a fresh project then indeed perhaps we would use GitHub issues but it's not nearly so compelling at this point with so much rich history in JIRA, not to mention those issues being referenced in commit messages.
>
> Is the point to lower barriers for contributors that are not in our community yet (thus don't have an ASF JIRA account)?  Well... they don't *have* to create the JIRA issue if a committer is sufficiently interested in the issue at hand to do it.  And as mentioned this could be automated.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <[hidden email]> wrote:
>>
>> FWIW, One thing that needs to be figured out is how github would accommodate security issues (or how the process for those issues would change).  Does github have the ability to assign roles and visibility (could be I haven't really worked with organizations on GitHub, all my clients have been on jira ... except the one that has trello, and another with gitlab... neither of which have impressed me very much )?
>>
>> Additionally, I'm slightly leery of the move since I don't (yet) see the real benefit that pays for the splitting of the records into two systems. Can issues be migrated to github? I've not really been on a large project that used only GitHub, can someone explain what we *gain* by moving to GitHub issues. At least two things are lost: continuity and familiarity. My impression is that there are a lot fewer features, but maybe I've just not been exposed to them.
>>
>> Part of me worries that this is the usual cycle of "this is simpler" (mass migration ensues) "but it doesn't x, y and z" (x, y and z are added) "wow this is complex, but THAT is simpler...." (mass migration ensues...) "hmm p, q an z are missing" (p q and z are added  and cycle repeats). So I'm skeptical of any "gain" hanging it's hat solely on "simplicity". Jira used to be the simpler, snazzier, sexier alternative to bugzilla...
>>
>> Sell me, I'm all ears, but not seeing it yet :)
>>
>> -Gus
>>
>> On Mon, Sep 16, 2019 at 3:57 PM Jan Høydahl <[hidden email]> wrote:
>>>
>>> Is there any reason at all that we need to hold on to JIRA? ASF allows us to move all issue handling over to GH, I'd like us to consider such a move.
>>>
>>> Until then, I made a script that "diffs" GH and JIRA and outputs a report, see https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy
>>>
>>> Running the tool shows that we're not very successful in keeping the two in sync, we also forget to close PRs after JIRAs are resolved:
>>>
>>> $ ./githubPRs.py
>>> Lucene/Solr Github PR report
>>> ============================
>>> Number of open Pull Requests: 208
>>>
>>> PRs lacking JIRA reference in title
>>>   #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
>>>   #880: Tweak header format.
>>>   [… many more ]
>>>
>>> Open PRs with a resolved JIRA
>>>   #723: SOLR-13545 status=Closed, resolution=Fixed, resolutiondate=2019-06-22T13:04:47.000+0000 (SOLR-13545: AutoClose stream in ContentStreamUpdateRequest)
>>>   #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
>>>   [… many more]
>>>
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>>
>>> 16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <[hidden email]>:
>>>
>>>
>>> On 16 Sep 2019, at 19:38, Yonik Seeley <[hidden email]> wrote:
>>>
>>> >  - PR is opened - should automatically create a jira if it doesn’t exist yet
>>>
>>> What were the reasons behind this? Shouldn't a JIRA just be optional if we started with a PR?
>>>
>>>
>>> That’s why we need to discuss this :)
>>>
>>> I remember that at some point ASF treated JIRA as the system of record for the legal validation of contributions.
>>>
>>> I also remember that at some point we used to say that if a discussion didn’t happen in JIRA then it didn’t exist, and that any decisions regarding code should be recorded in JIRA because we can’t expect people to monitor and contribute / object to decisions happening elsewhere.
>>>
>>> —
>>>
>>> Andrzej Białecki
>>>
>>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>
> _______________________
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Anshum Gupta
I think standardizing the approach to contributing would be a great thing. It might mean not accommodating everyone's preference, but then it would mean that the people who want to review are all on the same page. Else people who prefer git will rarely look at patches, and the other way around.

The major concern that was brought up during the committer meeting was around the history that is in JIRA archives. However, that shouldn't stop us from creating "all" new issues in GitHub if everyone agrees.

Anshum

On Tue, Sep 17, 2019 at 1:59 PM Mark Miller <[hidden email]> wrote:
I think I may prefer JIRA to GitHub Issues. I'm not sure.

Anyway, it's worth wondering if we can just move JIRA to GitHub. GitHub is now a first class mirror for Apache that we can commit to, but they still keep a primary copy of our code at Apache. Perhaps that is only a code concern now though.


As far as the GitHub vs patch issue, I don't want tell everyone they can't use patches, I usually prefer them, but, if we pushed everything through GitHub we can take super advantage of their free and way nicer than what we will ever have at Apache, Actions CI stuff. I'm not saying that will drive unit tests now or something, but for things like precommit and other checks (beasting on new tests or whatever), everyone going through that would be great. Would be awesome to project ourselves well in front of prs, or end up using the 2 branches and promoting changes when they are checked more thoroughly.

If we started using Git primarily that way, not using issues is probably more friction than we need ...

Mark

On Tue, Sep 17, 2019 at 2:46 PM David Smiley <[hidden email]> wrote:
Well put Jason.  I think we didn't discuss it in any further detail than what you said right here -- basically cater to GitHub PRs and either discourage or undocument "patch file" based contributions.  That's it in a sentence.  We all nodded our head to that, albeit some of us like me confess to enjoying the ease of patch based contributions.

~ David Smiley
Apache Lucene/Solr Search Developer


On Tue, Sep 17, 2019 at 9:46 AM Jason Gerlowski <[hidden email]> wrote:
I missed the part of the meeting/lunch when our use of Github came up.
Can anyone that was present summarize the discussion in a little more
detail?

re: issues on github.  There are challenges like avoiding
fragmentation and keeping multiple issue sources up to date, but those
are problems that probably shrink or go away with appropriate
automation.  IMO at least, issue reporting is largely the same whether
you're on Github, JIRA, trello, etc.  You fill out a form, set the
appropriate tags and fields, etc.  I'm fine w/ changes there, but it's
hard for me to imagine how that would have much/any impact on barrier
to entry.

I see our code-contribution process as a much bigger driver of the
barrier-to-entry. First time contributors must learn how to generate
patches.  They receive code-review on JIRA, so they get one chunk of
text in a comment.  And contributions have very weak version control
(identically named SOLR-####.patch files piling up on the same issue).
Github has concrete benefits here.  If the goal is to make it easier
for contributors to get involved, making Github first-class for code
contributions might be where the real gains are.  (We allow Github
PR's, but could steer people towards them more clearly: rewrite
HowToContribute docs to assume Github, hide the patch process for new
contributors, set up workflows in Github to run precommit/tests on
PRs, etc.)

On Tue, Sep 17, 2019 at 8:56 AM Eric Pugh
<[hidden email]> wrote:
>
> Ah..   The mythical committer just sitting around waiting to be “interested in the issue” that you have created!   Having said that, I think thats a separate challenge!
>
>
> On Sep 17, 2019, at 12:38 AM, David Smiley <[hidden email]> wrote:
>
> +1 to all that Gus said.  On a fresh project then indeed perhaps we would use GitHub issues but it's not nearly so compelling at this point with so much rich history in JIRA, not to mention those issues being referenced in commit messages.
>
> Is the point to lower barriers for contributors that are not in our community yet (thus don't have an ASF JIRA account)?  Well... they don't *have* to create the JIRA issue if a committer is sufficiently interested in the issue at hand to do it.  And as mentioned this could be automated.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <[hidden email]> wrote:
>>
>> FWIW, One thing that needs to be figured out is how github would accommodate security issues (or how the process for those issues would change).  Does github have the ability to assign roles and visibility (could be I haven't really worked with organizations on GitHub, all my clients have been on jira ... except the one that has trello, and another with gitlab... neither of which have impressed me very much )?
>>
>> Additionally, I'm slightly leery of the move since I don't (yet) see the real benefit that pays for the splitting of the records into two systems. Can issues be migrated to github? I've not really been on a large project that used only GitHub, can someone explain what we *gain* by moving to GitHub issues. At least two things are lost: continuity and familiarity. My impression is that there are a lot fewer features, but maybe I've just not been exposed to them.
>>
>> Part of me worries that this is the usual cycle of "this is simpler" (mass migration ensues) "but it doesn't x, y and z" (x, y and z are added) "wow this is complex, but THAT is simpler...." (mass migration ensues...) "hmm p, q an z are missing" (p q and z are added  and cycle repeats). So I'm skeptical of any "gain" hanging it's hat solely on "simplicity". Jira used to be the simpler, snazzier, sexier alternative to bugzilla...
>>
>> Sell me, I'm all ears, but not seeing it yet :)
>>
>> -Gus
>>
>> On Mon, Sep 16, 2019 at 3:57 PM Jan Høydahl <[hidden email]> wrote:
>>>
>>> Is there any reason at all that we need to hold on to JIRA? ASF allows us to move all issue handling over to GH, I'd like us to consider such a move.
>>>
>>> Until then, I made a script that "diffs" GH and JIRA and outputs a report, see https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy
>>>
>>> Running the tool shows that we're not very successful in keeping the two in sync, we also forget to close PRs after JIRAs are resolved:
>>>
>>> $ ./githubPRs.py
>>> Lucene/Solr Github PR report
>>> ============================
>>> Number of open Pull Requests: 208
>>>
>>> PRs lacking JIRA reference in title
>>>   #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
>>>   #880: Tweak header format.
>>>   [… many more ]
>>>
>>> Open PRs with a resolved JIRA
>>>   #723: SOLR-13545 status=Closed, resolution=Fixed, resolutiondate=2019-06-22T13:04:47.000+0000 (SOLR-13545: AutoClose stream in ContentStreamUpdateRequest)
>>>   #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
>>>   [… many more]
>>>
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>>
>>> 16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <[hidden email]>:
>>>
>>>
>>> On 16 Sep 2019, at 19:38, Yonik Seeley <[hidden email]> wrote:
>>>
>>> >  - PR is opened - should automatically create a jira if it doesn’t exist yet
>>>
>>> What were the reasons behind this? Shouldn't a JIRA just be optional if we started with a PR?
>>>
>>>
>>> That’s why we need to discuss this :)
>>>
>>> I remember that at some point ASF treated JIRA as the system of record for the legal validation of contributions.
>>>
>>> I also remember that at some point we used to say that if a discussion didn’t happen in JIRA then it didn’t exist, and that any decisions regarding code should be recorded in JIRA because we can’t expect people to monitor and contribute / object to decisions happening elsewhere.
>>>
>>> —
>>>
>>> Andrzej Białecki
>>>
>>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>
> _______________________
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Chris Hostetter-3
In reply to this post by Jan Høydahl / Cominvent

: Is there any reason at all that we need to hold on to JIRA? ASF allows
: us to move all issue handling over to GH, I'd like us to consider such a
: move.

In my opinion, migrating from JIRA to Github "issues" would be a terrible
idea.

I have no objections to the goal of "encouraging" and "facilitating"
contributions via github from people already using github -- but making
github the defacto (or *sole*) way to participate and contribute code
means pressuring people into accepting the github TOS (not just
now, but whatever those might be in the future) as well as making it
virtually impossible for people to participate if they are in locations
github has decided to block (ie: Iran, Syria, and Crimea ATM + whomever
else the US decides to sanction down the road)

Opening up, or expanding, pathways for participation is one thing --
I'm all in favor of that (even if I personally can't stand those avenues).

But *closing* existing path ways that are currently entirely "open" and
"free" to anyone that wants to participate w/o any limitations or TOS
other then "Provide an ASF controled and owned website with an email
address" ... that's just sad.


-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Gus Heck
"means pressuring people into accepting the github TOS"

That's a really good point. Hadn't thought of that and it's definitely not ok to put github in control (or make them able to force a sudden burden of work when we don't like what they did). Apache should determine it's own destiny, and for that to be true, Apache must have it's own infrastructure. Keep in mind who owns Github, and ponder what, prior to their embracing open source, they might have done to give IIS an edge over httpd... for example. They are playing nice now, but there's no guarantee that will remain true for all time.

On Tue, Sep 17, 2019 at 5:16 PM Chris Hostetter <[hidden email]> wrote:

: Is there any reason at all that we need to hold on to JIRA? ASF allows
: us to move all issue handling over to GH, I'd like us to consider such a
: move.

In my opinion, migrating from JIRA to Github "issues" would be a terrible
idea.

I have no objections to the goal of "encouraging" and "facilitating"
contributions via github from people already using github -- but making
github the defacto (or *sole*) way to participate and contribute code
means pressuring people into accepting the github TOS (not just
now, but whatever those might be in the future) as well as making it
virtually impossible for people to participate if they are in locations
github has decided to block (ie: Iran, Syria, and Crimea ATM + whomever
else the US decides to sanction down the road)

Opening up, or expanding, pathways for participation is one thing --
I'm all in favor of that (even if I personally can't stand those avenues).

But *closing* existing path ways that are currently entirely "open" and
"free" to anyone that wants to participate w/o any limitations or TOS
other then "Provide an ASF controled and owned website with an email
address" ... that's just sad.


-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Anshum Gupta
In reply to this post by Chris Hostetter-3
Ok, I buy that reason for leaving the ASF controlled mechanism. 

On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <[hidden email]> wrote:

: Is there any reason at all that we need to hold on to JIRA? ASF allows
: us to move all issue handling over to GH, I'd like us to consider such a
: move.

In my opinion, migrating from JIRA to Github "issues" would be a terrible
idea.

I have no objections to the goal of "encouraging" and "facilitating"
contributions via github from people already using github -- but making
github the defacto (or *sole*) way to participate and contribute code
means pressuring people into accepting the github TOS (not just
now, but whatever those might be in the future) as well as making it
virtually impossible for people to participate if they are in locations
github has decided to block (ie: Iran, Syria, and Crimea ATM + whomever
else the US decides to sanction down the road)

Opening up, or expanding, pathways for participation is one thing --
I'm all in favor of that (even if I personally can't stand those avenues).

But *closing* existing path ways that are currently entirely "open" and
"free" to anyone that wants to participate w/o any limitations or TOS
other then "Provide an ASF controled and owned website with an email
address" ... that's just sad.


-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Mark Miller-3
I think that is a little over the top.

As it is the majority of dev and pr's and action is moving to GitHub, whether anyone is from Syria or not.

If we decided, like most other communities on Gods green earth, to tell our community we are going GitHub first it and expect committers to not avoid all of our checks by just sticking to patches, the practical differences don't have to be much beyond that. Apache GitBox is not going away, it's easy to clearly spell out that those without access to GitHub can provide a patch as we would allow any committer without access or moral quandaries the same obviously. Making how to contribute a patch and use JIRA alternate doc for those with GitHub issues is pretty low effort.

JIRA is a little different, I'm not as sold on leaving it, but really it's the same thing if almost all of the dev community starts using it for the bulk of what would be in JIRA, already lots of JIRA related comments and review have gone there - most stuff is just split instead of "free and available" - GitHub is lacking, JIRA is lacking.  Given that every damn company and project is on GitHub, this is just the way it will continue to go. So leaving JIRA up for history and those without access to GitHub would be the same too.

And if M$ does anything with GitHub, the universe will collectively move on, with 90% of the world in the same spot. Great opportunity will emerge if that happens. Join me in a startup :)

It sounds great to be like, freedom, TOS and "Sad!" but practically it's all meaningless.

This is happening and will happen. Like I once said Git was inevitable and just shut up until it came, this is the same. 

"Us" as a community deciding to embrace it just means 3-4 old curmudgeons in a year won't as likely still be holding onto old ways for the sake of a imagined victim. Anyone that doesn't want to accept the GitHub TOS would get the same deal as someone from Siria. They will get the same 2nd citizen experience they are currently enjoying and that will continue to grow.

And whatever you say or whatever the day, the practical difference of what happens will be zilch except for one thing: some people will feel better about bucking the community even if they are not from Syria or morally against the GitHub TOS.

I'm a big fan of the kicking of screaming way, but generally only in my personal life. Professionally, I like to embrace the practical.

 

On Tue, Sep 17, 2019 at 4:59 PM Anshum Gupta <[hidden email]> wrote:
Ok, I buy that reason for leaving the ASF controlled mechanism. 

On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <[hidden email]> wrote:

: Is there any reason at all that we need to hold on to JIRA? ASF allows
: us to move all issue handling over to GH, I'd like us to consider such a
: move.

In my opinion, migrating from JIRA to Github "issues" would be a terrible
idea.

I have no objections to the goal of "encouraging" and "facilitating"
contributions via github from people already using github -- but making
github the defacto (or *sole*) way to participate and contribute code
means pressuring people into accepting the github TOS (not just
now, but whatever those might be in the future) as well as making it
virtually impossible for people to participate if they are in locations
github has decided to block (ie: Iran, Syria, and Crimea ATM + whomever
else the US decides to sanction down the road)

Opening up, or expanding, pathways for participation is one thing --
I'm all in favor of that (even if I personally can't stand those avenues).

But *closing* existing path ways that are currently entirely "open" and
"free" to anyone that wants to participate w/o any limitations or TOS
other then "Provide an ASF controled and owned website with an email
address" ... that's just sad.


-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Anshum Gupta


--
Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Mark Miller-3
Also, just FYI, I say that as someone that kind of prefers patches and JIRA for 90% of what I do. I’ve been doing this same shit for like half my life, I’m not looking for fancy new tools for the hell of it either. I like patches. It’s just going to happen. And I see a huge pool of free resources in the meantime, wow those workflow limits are not too bad at all. I could stop another new test that takes 2 minutes from coming in non nightly. Now that’s practically interesting.

Mark

On Tue, Sep 17, 2019 at 7:39 PM Mark Miller <[hidden email]> wrote:
I think that is a little over the top.

As it is the majority of dev and pr's and action is moving to GitHub, whether anyone is from Syria or not.

If we decided, like most other communities on Gods green earth, to tell our community we are going GitHub first it and expect committers to not avoid all of our checks by just sticking to patches, the practical differences don't have to be much beyond that. Apache GitBox is not going away, it's easy to clearly spell out that those without access to GitHub can provide a patch as we would allow any committer without access or moral quandaries the same obviously. Making how to contribute a patch and use JIRA alternate doc for those with GitHub issues is pretty low effort.

JIRA is a little different, I'm not as sold on leaving it, but really it's the same thing if almost all of the dev community starts using it for the bulk of what would be in JIRA, already lots of JIRA related comments and review have gone there - most stuff is just split instead of "free and available" - GitHub is lacking, JIRA is lacking.  Given that every damn company and project is on GitHub, this is just the way it will continue to go. So leaving JIRA up for history and those without access to GitHub would be the same too.

And if M$ does anything with GitHub, the universe will collectively move on, with 90% of the world in the same spot. Great opportunity will emerge if that happens. Join me in a startup :)

It sounds great to be like, freedom, TOS and "Sad!" but practically it's all meaningless.

This is happening and will happen. Like I once said Git was inevitable and just shut up until it came, this is the same. 

"Us" as a community deciding to embrace it just means 3-4 old curmudgeons in a year won't as likely still be holding onto old ways for the sake of a imagined victim. Anyone that doesn't want to accept the GitHub TOS would get the same deal as someone from Siria. They will get the same 2nd citizen experience they are currently enjoying and that will continue to grow.

And whatever you say or whatever the day, the practical difference of what happens will be zilch except for one thing: some people will feel better about bucking the community even if they are not from Syria or morally against the GitHub TOS.

I'm a big fan of the kicking of screaming way, but generally only in my personal life. Professionally, I like to embrace the practical.

 

On Tue, Sep 17, 2019 at 4:59 PM Anshum Gupta <[hidden email]> wrote:
Ok, I buy that reason for leaving the ASF controlled mechanism. 

On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <[hidden email]> wrote:

: Is there any reason at all that we need to hold on to JIRA? ASF allows
: us to move all issue handling over to GH, I'd like us to consider such a
: move.

In my opinion, migrating from JIRA to Github "issues" would be a terrible
idea.

I have no objections to the goal of "encouraging" and "facilitating"
contributions via github from people already using github -- but making
github the defacto (or *sole*) way to participate and contribute code
means pressuring people into accepting the github TOS (not just
now, but whatever those might be in the future) as well as making it
virtually impossible for people to participate if they are in locations
github has decided to block (ie: Iran, Syria, and Crimea ATM + whomever
else the US decides to sanction down the road)

Opening up, or expanding, pathways for participation is one thing --
I'm all in favor of that (even if I personally can't stand those avenues).

But *closing* existing path ways that are currently entirely "open" and
"free" to anyone that wants to participate w/o any limitations or TOS
other then "Provide an ASF controled and owned website with an email
address" ... that's just sad.


-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Anshum Gupta


--
--
Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Gus Heck
I wrote quickly and didn't expound much, let me clarify that my comments are in reference to having bug tracking in GitHub. Using the mirror doesn't bother me since the system of record is apache gitbox (the GitHub mirror is WAY better UI than gitbox). Having the record of what bugs were resolved in what versions and the thought that went into it, only exist outside apache is all I'm worried about. I'm not anti git, nor am I anti code review in GitHub, as long as major direction changes and decisions s are summarized in jira, or in code comments. I also have generally assumed that pull request reviews were meant to mostly be code review, i.e. focused comments on specific lines or classes . Discussion of how to solve bugs or possible directions for features would be in jira.

In more concrete terms one thing I will definitely miss if we go to GitHub is the tabular view of issues, especially the ability to sort by issue ID which I use regularly to get a view of (roughly) chronologically history of changes on a topic. I really find their way of listing issues very hard to read. It would be much easier to scan down a column of milestones for example. 

By the way, how would we plan to handle fix versions in GitHub issues? Milestones? What about affects version etc.

And I don't agree that "everyone is on GitHub" I still have yet to encounter a single client site that was using GitHub (~20 clients in 6 years ranging from 1 man startups to Fortune 50 companies). Plenty using git, often bitbucket, but nobody using github itself. Plenty of open source projects (including minor ones I started) use GitHub... But the idea that folks out there won't know how to adapt to anything other than GitHub seems preposterous to me. The only folks who are not going to be able to absorb a new bug tracking system are the very junior devs, few of whom will be looking to contribute to Solr I think. Honestly the popularity of python as a teaching language is a much bigger threat to our ability to attract fresh folks than our bug tracker choice...

So I'm not at all against GitHub having some role, but the degree of dependency on outside services seems important. I guess it's possible to see it as a question of what you consider peripheral vs core. I think records of the issues are core, but code review comments not so much.

Also it seems ironic that I'm writing this mail to clarify I'm not entirely against Github as I wait for a *forced* reboot to finish on my Windows machine... One that hit while I was in the middle of something else... 

-Gus


On Tue, Sep 17, 2019, 9:01 PM Mark Miller <[hidden email]> wrote:
Also, just FYI, I say that as someone that kind of prefers patches and JIRA for 90% of what I do. I’ve been doing this same shit for like half my life, I’m not looking for fancy new tools for the hell of it either. I like patches. It’s just going to happen. And I see a huge pool of free resources in the meantime, wow those workflow limits are not too bad at all. I could stop another new test that takes 2 minutes from coming in non nightly. Now that’s practically interesting.

Mark

On Tue, Sep 17, 2019 at 7:39 PM Mark Miller <[hidden email]> wrote:
I think that is a little over the top.

As it is the majority of dev and pr's and action is moving to GitHub, whether anyone is from Syria or not.

If we decided, like most other communities on Gods green earth, to tell our community we are going GitHub first it and expect committers to not avoid all of our checks by just sticking to patches, the practical differences don't have to be much beyond that. Apache GitBox is not going away, it's easy to clearly spell out that those without access to GitHub can provide a patch as we would allow any committer without access or moral quandaries the same obviously. Making how to contribute a patch and use JIRA alternate doc for those with GitHub issues is pretty low effort.

JIRA is a little different, I'm not as sold on leaving it, but really it's the same thing if almost all of the dev community starts using it for the bulk of what would be in JIRA, already lots of JIRA related comments and review have gone there - most stuff is just split instead of "free and available" - GitHub is lacking, JIRA is lacking.  Given that every damn company and project is on GitHub, this is just the way it will continue to go. So leaving JIRA up for history and those without access to GitHub would be the same too.

And if M$ does anything with GitHub, the universe will collectively move on, with 90% of the world in the same spot. Great opportunity will emerge if that happens. Join me in a startup :)

It sounds great to be like, freedom, TOS and "Sad!" but practically it's all meaningless.

This is happening and will happen. Like I once said Git was inevitable and just shut up until it came, this is the same. 

"Us" as a community deciding to embrace it just means 3-4 old curmudgeons in a year won't as likely still be holding onto old ways for the sake of a imagined victim. Anyone that doesn't want to accept the GitHub TOS would get the same deal as someone from Siria. They will get the same 2nd citizen experience they are currently enjoying and that will continue to grow.

And whatever you say or whatever the day, the practical difference of what happens will be zilch except for one thing: some people will feel better about bucking the community even if they are not from Syria or morally against the GitHub TOS.

I'm a big fan of the kicking of screaming way, but generally only in my personal life. Professionally, I like to embrace the practical.

 

On Tue, Sep 17, 2019 at 4:59 PM Anshum Gupta <[hidden email]> wrote:
Ok, I buy that reason for leaving the ASF controlled mechanism. 

On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <[hidden email]> wrote:

: Is there any reason at all that we need to hold on to JIRA? ASF allows
: us to move all issue handling over to GH, I'd like us to consider such a
: move.

In my opinion, migrating from JIRA to Github "issues" would be a terrible
idea.

I have no objections to the goal of "encouraging" and "facilitating"
contributions via github from people already using github -- but making
github the defacto (or *sole*) way to participate and contribute code
means pressuring people into accepting the github TOS (not just
now, but whatever those might be in the future) as well as making it
virtually impossible for people to participate if they are in locations
github has decided to block (ie: Iran, Syria, and Crimea ATM + whomever
else the US decides to sanction down the road)

Opening up, or expanding, pathways for participation is one thing --
I'm all in favor of that (even if I personally can't stand those avenues).

But *closing* existing path ways that are currently entirely "open" and
"free" to anyone that wants to participate w/o any limitations or TOS
other then "Provide an ASF controled and owned website with an email
address" ... that's just sad.


-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Anshum Gupta


--
--
Reply | Threaded
Open this post in threaded view
|

Re: Notes from the committers' meeting at Activate 2019

Jan Høydahl / Cominvent
We as a project won't need to worry about "system of record" or what MS will do in the future. Really.
I encourage all to read INFRA's post about the ASF-GitHub agreement here https://blogs.apache.org/infra/entry/apache-and-github-a-friendly
In the last paragraph it states:

For many projects, the move to GitHub means a lower bar to both contributing as well as troubleshooting and submitting issues to the projects, through the GitHub issue and pull request features.
Our commitment to provenance, quality and open governance remains the same, and with our tight integration with GitHub through our linked account service, we are able to bring what made Apache a mark of quality to the many users and contributors on GitHub.

ASF has us legally covered, and from the foundation's side, GitHub issues is equal to JIRA issues and GitHub PRs are equal to patches in JIRA.

INFRA also clearly states in the same post that:

People that wish to continue using their Apache committer accounts to commit code may continue doing so on gitbox.apache.org with their Apache credentials. Nothing has changed in that respect.

So the argument against TOS or personal M$ dislikes or principles won't hold here.

We can continue accepting JIRA issues, patches and commits to GitBox for those who favor those tools for any reason.
But we can equally well embrace the entire GitHub tooling which was made available to us by ASF earlier this year, and make that the de facto (and primary documented) way of interacting with Lucene/Solr.
I'd prefer a complete switch like Accumulo did, as a dual tracker situation is a bit of a mess. A third option is to automate the creation of linked shadow issues in GH for new JIRA issues that gets created from Syria :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

18. sep. 2019 kl. 06:58 skrev Gus Heck <[hidden email]>:

I wrote quickly and didn't expound much, let me clarify that my comments are in reference to having bug tracking in GitHub. Using the mirror doesn't bother me since the system of record is apache gitbox (the GitHub mirror is WAY better UI than gitbox). Having the record of what bugs were resolved in what versions and the thought that went into it, only exist outside apache is all I'm worried about. I'm not anti git, nor am I anti code review in GitHub, as long as major direction changes and decisions s are summarized in jira, or in code comments. I also have generally assumed that pull request reviews were meant to mostly be code review, i.e. focused comments on specific lines or classes . Discussion of how to solve bugs or possible directions for features would be in jira.

In more concrete terms one thing I will definitely miss if we go to GitHub is the tabular view of issues, especially the ability to sort by issue ID which I use regularly to get a view of (roughly) chronologically history of changes on a topic. I really find their way of listing issues very hard to read. It would be much easier to scan down a column of milestones for example. 

By the way, how would we plan to handle fix versions in GitHub issues? Milestones? What about affects version etc.

And I don't agree that "everyone is on GitHub" I still have yet to encounter a single client site that was using GitHub (~20 clients in 6 years ranging from 1 man startups to Fortune 50 companies). Plenty using git, often bitbucket, but nobody using github itself. Plenty of open source projects (including minor ones I started) use GitHub... But the idea that folks out there won't know how to adapt to anything other than GitHub seems preposterous to me. The only folks who are not going to be able to absorb a new bug tracking system are the very junior devs, few of whom will be looking to contribute to Solr I think. Honestly the popularity of python as a teaching language is a much bigger threat to our ability to attract fresh folks than our bug tracker choice...

So I'm not at all against GitHub having some role, but the degree of dependency on outside services seems important. I guess it's possible to see it as a question of what you consider peripheral vs core. I think records of the issues are core, but code review comments not so much.

Also it seems ironic that I'm writing this mail to clarify I'm not entirely against Github as I wait for a *forced* reboot to finish on my Windows machine... One that hit while I was in the middle of something else... 

-Gus


On Tue, Sep 17, 2019, 9:01 PM Mark Miller <[hidden email]> wrote:
Also, just FYI, I say that as someone that kind of prefers patches and JIRA for 90% of what I do. I’ve been doing this same shit for like half my life, I’m not looking for fancy new tools for the hell of it either. I like patches. It’s just going to happen. And I see a huge pool of free resources in the meantime, wow those workflow limits are not too bad at all. I could stop another new test that takes 2 minutes from coming in non nightly. Now that’s practically interesting.

Mark

On Tue, Sep 17, 2019 at 7:39 PM Mark Miller <[hidden email]> wrote:
I think that is a little over the top.

As it is the majority of dev and pr's and action is moving to GitHub, whether anyone is from Syria or not.

If we decided, like most other communities on Gods green earth, to tell our community we are going GitHub first it and expect committers to not avoid all of our checks by just sticking to patches, the practical differences don't have to be much beyond that. Apache GitBox is not going away, it's easy to clearly spell out that those without access to GitHub can provide a patch as we would allow any committer without access or moral quandaries the same obviously. Making how to contribute a patch and use JIRA alternate doc for those with GitHub issues is pretty low effort.

JIRA is a little different, I'm not as sold on leaving it, but really it's the same thing if almost all of the dev community starts using it for the bulk of what would be in JIRA, already lots of JIRA related comments and review have gone there - most stuff is just split instead of "free and available" - GitHub is lacking, JIRA is lacking.  Given that every damn company and project is on GitHub, this is just the way it will continue to go. So leaving JIRA up for history and those without access to GitHub would be the same too.

And if M$ does anything with GitHub, the universe will collectively move on, with 90% of the world in the same spot. Great opportunity will emerge if that happens. Join me in a startup :)

It sounds great to be like, freedom, TOS and "Sad!" but practically it's all meaningless.

This is happening and will happen. Like I once said Git was inevitable and just shut up until it came, this is the same. 

"Us" as a community deciding to embrace it just means 3-4 old curmudgeons in a year won't as likely still be holding onto old ways for the sake of a imagined victim. Anyone that doesn't want to accept the GitHub TOS would get the same deal as someone from Siria. They will get the same 2nd citizen experience they are currently enjoying and that will continue to grow.

And whatever you say or whatever the day, the practical difference of what happens will be zilch except for one thing: some people will feel better about bucking the community even if they are not from Syria or morally against the GitHub TOS.

I'm a big fan of the kicking of screaming way, but generally only in my personal life. Professionally, I like to embrace the practical.

 

On Tue, Sep 17, 2019 at 4:59 PM Anshum Gupta <[hidden email]> wrote:
Ok, I buy that reason for leaving the ASF controlled mechanism. 

On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <[hidden email]> wrote:

: Is there any reason at all that we need to hold on to JIRA? ASF allows
: us to move all issue handling over to GH, I'd like us to consider such a
: move.

In my opinion, migrating from JIRA to Github "issues" would be a terrible
idea.

I have no objections to the goal of "encouraging" and "facilitating"
contributions via github from people already using github -- but making
github the defacto (or *sole*) way to participate and contribute code
means pressuring people into accepting the github TOS (not just
now, but whatever those might be in the future) as well as making it
virtually impossible for people to participate if they are in locations
github has decided to block (ie: Iran, Syria, and Crimea ATM + whomever
else the US decides to sanction down the road)

Opening up, or expanding, pathways for participation is one thing --
I'm all in favor of that (even if I personally can't stand those avenues).

But *closing* existing path ways that are currently entirely "open" and
"free" to anyone that wants to participate w/o any limitations or TOS
other then "Provide an ASF controled and owned website with an email
address" ... that's just sad.


-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Anshum Gupta


--
--

12