You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Andrzej Białecki <ab...@getopt.org> on 2019/09/16 11:23:30 UTC
Notes from the committers' meeting at Activate 2019
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Notes from the committers' meeting at Activate 2019
Posted by David Smiley <da...@gmail.com>.
You could create the issue if you are so inclined. The "author" metadata
of the issue might not be quite right but that's quite minor... and could
be ameliorated with mentioning the original author in the description.
Multiple sources of truth is troubling to me and of course complicates
tracking project activity.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Sun, Sep 29, 2019 at 10:08 PM Varun Thacker <va...@vthacker.in> wrote:
> I have a question for a PR like this -
> https://github.com/apache/lucene-solr/pull/908/
>
> This user is a first time contributor and now we have to ask the user to
> create a tracking Jira for a PR before we can commit this - Is there a
> process we can take that can make this smoother for the user?
>
> PR is opened - should automatically create a jira if it doesn’t exist yet
>>
>
> This would have definitely helped , but could we just commit this with the
> PR number in the CHANGES file ? I'm not sold on this idea completely myself
> because you now have two sources of truths , but that will still happen if
> we create a Jira ( the inline code reviews etc would be in the PR )
>
>
> On Thu, Sep 19, 2019 at 12:57 PM Noble Paul <no...@gmail.com> wrote:
>
>> My 2 sents
>> I like the workflow of PR and code review in github.
>> But, I still prefer JIRA and I don't want it to replace it with github
>> issues
>>
>> On Tue, Sep 17, 2019 at 5:57 AM Jan Høydahl <ja...@cominvent.com>
>> 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 <ab...@getopt.org>:
>> >
>> >
>> > On 16 Sep 2019, at 19:38, Yonik Seeley <ys...@gmail.com> 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
>> >
>> >
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: Notes from the committers' meeting at Activate 2019
Posted by Varun Thacker <va...@vthacker.in>.
I have a question for a PR like this -
https://github.com/apache/lucene-solr/pull/908/
This user is a first time contributor and now we have to ask the user to
create a tracking Jira for a PR before we can commit this - Is there a
process we can take that can make this smoother for the user?
PR is opened - should automatically create a jira if it doesn’t exist yet
>
This would have definitely helped , but could we just commit this with the
PR number in the CHANGES file ? I'm not sold on this idea completely myself
because you now have two sources of truths , but that will still happen if
we create a Jira ( the inline code reviews etc would be in the PR )
On Thu, Sep 19, 2019 at 12:57 PM Noble Paul <no...@gmail.com> wrote:
> My 2 sents
> I like the workflow of PR and code review in github.
> But, I still prefer JIRA and I don't want it to replace it with github
> issues
>
> On Tue, Sep 17, 2019 at 5:57 AM Jan Høydahl <ja...@cominvent.com> 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 <ab...@getopt.org>:
> >
> >
> > On 16 Sep 2019, at 19:38, Yonik Seeley <ys...@gmail.com> 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
> >
> >
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Notes from the committers' meeting at Activate 2019
Posted by Noble Paul <no...@gmail.com>.
My 2 sents
I like the workflow of PR and code review in github.
But, I still prefer JIRA and I don't want it to replace it with github issues
On Tue, Sep 17, 2019 at 5:57 AM Jan Høydahl <ja...@cominvent.com> 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 <ab...@getopt.org>:
>
>
> On 16 Sep 2019, at 19:38, Yonik Seeley <ys...@gmail.com> 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
>
>
--
-----------------------------------------------------
Noble Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Notes from the committers' meeting at Activate 2019
Posted by Gus Heck <gu...@gmail.com>.
"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 <ho...@fucit.org>
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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Notes from the committers' meeting at Activate 2019
Posted by Gus Heck <gu...@gmail.com>.
Yes I've used that GitHub issues interface many many times and IMHO and it
sucks. I put up with it because it's free and I'm not rich. I have a small
herd of stuff I have tossed up in git hub over the years across 2 accounts,
and I maintain JesterJ in GitHub... I'd move it to Jira in a heart beat if
there were a way to offer access to others for free. The Jira interface is
much much better for searching/displaying/sorting issues. It's easier to
see fields on the issues (because tables make it possible to predict where
on the screen you will find the information more accurately, and your eyes
can go right to it without having to read the whole line!). Jira has more
fields, ability to add custom fields, ability to filter and sort on *any*
field including said custom fields. It's also easier to add or eliminate
fields you actually care about (column configuration) and easier to save
searches you use frequently (haven't done that latter as much with
lucene/solr but definitely like it elsewhere). AFAIK GitHub has almost none
of that, let alone ability to define workflows or differentiate access to
issues via roles. From an Issue perspective GitHub issues are no more
flexible and no more feature rich than Bugzilla was when I first
encountered it in 2002. The main thing they have going for them is the
tight integration with VCS (close with comment etc) and that they are
free... and unlike Bugzilla it's hosted so you don't have to put work into
maintenance, or find a server to run it on.
It's entirely possible that there's added stuff unlocked with paid
organizations in GitHub that I haven't seen, or other features I just
haven't discovered, but as I see it the base thing I see and interact with
on most open source projects is very meh but very free, and I think that
free bit is the only reason it's so popular.
-Gus
On Wed, Sep 18, 2019 at 8:26 AM Erick Erickson <er...@gmail.com>
wrote:
> It seems like there are two discussions happening here
> 1> moving code _development_ to GitHub
> 2> moving JIRA to GitHub
>
> I want to talk about <2>
>
> Gus:
>
> Have you looked at "issues" in GitHub? See:
>
> https://github.com/apache/accumulo/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
>
> On a _very_ quick look, my two main concerns about moving off JIRA are
> addressed:
> 1> being able to search/sort issues
> 2> seeing the discussion that went into whatever the end result was
> for a particular issue
>
> Anything else you do regularly that's not supported? Originally this
> was a long scree about why JIRA needs to remain, but as long as JIRA
> remains at least available for archival reasons and the two functions
> above are available, I can probably adapt. It'd be awkward to have to
> go to two places of course.
>
> That said, I have no interest at all in moving away from JIRA unless
> there are very clear advantages. Having to go to JIRA to see the
> discussion seems like a minimal barrier to entry IMO. Using GitHub for
> code development is compatible with staying on JIRA.
>
> On Wed, Sep 18, 2019 at 4:23 AM Jan Høydahl <ja...@cominvent.com> wrote:
> >
> > 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 <gu...@gmail.com>:
> >
> > 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 <ma...@gmail.com> 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 <ma...@gmail.com>
> 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 <an...@anshumgupta.net>
> wrote:
> >>>>
> >>>> Ok, I buy that reason for leaving the ASF controlled mechanism.
> >>>>
> >>>> On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <
> hossman_lucene@fucit.org> 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: dev-unsubscribe@lucene.apache.org
> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Anshum Gupta
> >>>
> >>>
> >>>
> >>> --
> >>> - Mark
> >>>
> >>> http://about.me/markrmiller
> >>
> >> --
> >> - Mark
> >>
> >> http://about.me/markrmiller
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Notes from the committers' meeting at Activate 2019
Posted by Erick Erickson <er...@gmail.com>.
It seems like there are two discussions happening here
1> moving code _development_ to GitHub
2> moving JIRA to GitHub
I want to talk about <2>
Gus:
Have you looked at "issues" in GitHub? See:
https://github.com/apache/accumulo/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
On a _very_ quick look, my two main concerns about moving off JIRA are
addressed:
1> being able to search/sort issues
2> seeing the discussion that went into whatever the end result was
for a particular issue
Anything else you do regularly that's not supported? Originally this
was a long scree about why JIRA needs to remain, but as long as JIRA
remains at least available for archival reasons and the two functions
above are available, I can probably adapt. It'd be awkward to have to
go to two places of course.
That said, I have no interest at all in moving away from JIRA unless
there are very clear advantages. Having to go to JIRA to see the
discussion seems like a minimal barrier to entry IMO. Using GitHub for
code development is compatible with staying on JIRA.
On Wed, Sep 18, 2019 at 4:23 AM Jan Høydahl <ja...@cominvent.com> wrote:
>
> 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 <gu...@gmail.com>:
>
> 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 <ma...@gmail.com> 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 <ma...@gmail.com> 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 <an...@anshumgupta.net> wrote:
>>>>
>>>> Ok, I buy that reason for leaving the ASF controlled mechanism.
>>>>
>>>> On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <ho...@fucit.org> 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: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>
>>>>
>>>> --
>>>> Anshum Gupta
>>>
>>>
>>>
>>> --
>>> - Mark
>>>
>>> http://about.me/markrmiller
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Notes from the committers' meeting at Activate 2019
Posted by Chris Hostetter <ho...@fucit.org>.
: 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.
: > 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
Ok -- everybody chill for a second.
I made a specific comment regarding github TOS/access in response to a
*very* specific suggestion.
As a refresher, the specific suggestion i was responding to was this...
: > : 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.
...that's it. *replacing* JIRA with github-issues is the specific idea i
was saying was terrible.
Arguments that the code is still safe, and that committers who don't trust
github can still push directly to gitbox w/o needing to accept 3rd party
TOS; and that patches in github PRs are just as legally valid as patches
in Jira are all fine -- but completely irrelevant to my comment.
Likewise: Arguments that people who don't agree to github TOS, or can't
access github could still be contribute via JIRA make zero sense in the
specific hypothetical scenerio i was replying to where JIRA no longer
exists.
As i said before: if folks want to encourage and facilitate more direct
integration and contributions & reviews via github -- using whatever weird
ass github workflows or integrations or "hooks" or whatnot that github
offers -- then cool, go for it, i'm all in favor of opening those doors
(evne if i don't plan on using them much).
what i objected to was *closing* a door (again: specificly, migrating off
of JIRA completely) that is currently open to anyone and saying it's not
neccessary because we've open a new door that comes with a lot of
restrictions and baggage.
: > 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Notes from the committers' meeting at Activate 2019
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <gu...@gmail.com>:
>
> 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 <markrmiller@gmail.com <ma...@gmail.com>> 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 <markrmiller@gmail.com <ma...@gmail.com>> 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 <anshum@anshumgupta.net <ma...@anshumgupta.net>> wrote:
> Ok, I buy that reason for leaving the ASF controlled mechanism.
>
> On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <hossman_lucene@fucit.org <ma...@fucit.org>> 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/ <http://www.lucidworks.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>
>
>
> --
> Anshum Gupta
>
>
> --
> - Mark
>
> http://about.me/markrmiller <http://about.me/markrmiller>
> --
> - Mark
>
> http://about.me/markrmiller <http://about.me/markrmiller>
Re: Notes from the committers' meeting at Activate 2019
Posted by Gus Heck <gu...@gmail.com>.
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 <ma...@gmail.com> 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 <ma...@gmail.com> 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 <an...@anshumgupta.net>
>> wrote:
>>
>>> Ok, I buy that reason for leaving the ASF controlled mechanism.
>>>
>>> On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <
>>> hossman_lucene@fucit.org> 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: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
> --
> - Mark
>
> http://about.me/markrmiller
>
Re: Notes from the committers' meeting at Activate 2019
Posted by Mark Miller <ma...@gmail.com>.
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 <ma...@gmail.com> 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 <an...@anshumgupta.net>
> wrote:
>
>> Ok, I buy that reason for leaving the ASF controlled mechanism.
>>
>> On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <ho...@fucit.org>
>> 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: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>> --
>> Anshum Gupta
>>
>
>
> --
> - Mark
>
> http://about.me/markrmiller
>
--
- Mark
http://about.me/markrmiller
Re: Notes from the committers' meeting at Activate 2019
Posted by Mark Miller <ma...@gmail.com>.
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 <an...@anshumgupta.net> wrote:
> Ok, I buy that reason for leaving the ASF controlled mechanism.
>
> On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <ho...@fucit.org>
> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> --
> Anshum Gupta
>
--
- Mark
http://about.me/markrmiller
Re: Notes from the committers' meeting at Activate 2019
Posted by Anshum Gupta <an...@anshumgupta.net>.
Ok, I buy that reason for leaving the ASF controlled mechanism.
On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter <ho...@fucit.org>
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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Anshum Gupta
Re: Notes from the committers' meeting at Activate 2019
Posted by Chris Hostetter <ho...@fucit.org>.
: 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Notes from the committers' meeting at Activate 2019
Posted by Anshum Gupta <an...@anshumgupta.net>.
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 <ma...@gmail.com> 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.
>
> It appears others have moved:
> https://accumulo.apache.org/blog/2018/03/16/moving-to-github-issues.html
>
> 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 <da...@gmail.com>
> 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
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Tue, Sep 17, 2019 at 9:46 AM Jason Gerlowski <ge...@gmail.com>
>> 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
>>> <ep...@opensourceconnections.com> 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 <da...@gmail.com>
>>> 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 <gu...@gmail.com> 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 <ja...@cominvent.com>
>>> 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 <ab...@getopt.org>:
>>> >>>
>>> >>>
>>> >>> On 16 Sep 2019, at 19:38, Yonik Seeley <ys...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>
> --
> - Mark
>
> http://about.me/markrmiller
>
--
Anshum Gupta
Re: Notes from the committers' meeting at Activate 2019
Posted by Mark Miller <ma...@gmail.com>.
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.
It appears others have moved:
https://accumulo.apache.org/blog/2018/03/16/moving-to-github-issues.html
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 <da...@gmail.com>
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
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Sep 17, 2019 at 9:46 AM Jason Gerlowski <ge...@gmail.com>
> 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
>> <ep...@opensourceconnections.com> 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 <da...@gmail.com>
>> 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 <gu...@gmail.com> 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 <ja...@cominvent.com>
>> 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 <ab...@getopt.org>:
>> >>>
>> >>>
>> >>> On 16 Sep 2019, at 19:38, Yonik Seeley <ys...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
--
- Mark
http://about.me/markrmiller
Re: Notes from the committers' meeting at Activate 2019
Posted by David Smiley <da...@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
http://www.linkedin.com/in/davidwsmiley
On Tue, Sep 17, 2019 at 9:46 AM Jason Gerlowski <ge...@gmail.com>
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
> <ep...@opensourceconnections.com> 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 <da...@gmail.com>
> 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 <gu...@gmail.com> 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 <ja...@cominvent.com>
> 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 <ab...@getopt.org>:
> >>>
> >>>
> >>> On 16 Sep 2019, at 19:38, Yonik Seeley <ys...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Notes from the committers' meeting at Activate 2019
Posted by Jason Gerlowski <ge...@gmail.com>.
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
<ep...@opensourceconnections.com> 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 <da...@gmail.com> 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 <gu...@gmail.com> 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 <ja...@cominvent.com> 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 <ab...@getopt.org>:
>>>
>>>
>>> On 16 Sep 2019, at 19:38, Yonik Seeley <ys...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Notes from the committers' meeting at Activate 2019
Posted by Eric Pugh <ep...@opensourceconnections.com>.
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 <da...@gmail.com> 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 <http://www.linkedin.com/in/davidwsmiley>
>
> On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> 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 <jan.asf@cominvent.com <ma...@cominvent.com>> 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 <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 <http://www.cominvent.com/>
>
>> 16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <ab@getopt.org <ma...@getopt.org>>:
>>
>>
>>> On 16 Sep 2019, at 19:38, Yonik Seeley <yseeley@gmail.com <ma...@gmail.com>> 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 <http://www.needhamsoftware.com/> (work)
> http://www.the111shift.com <http://www.the111shift.com/> (play)
_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
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.
Re: Notes from the committers' meeting at Activate 2019
Posted by David Smiley <da...@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
http://www.linkedin.com/in/davidwsmiley
On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <gu...@gmail.com> 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 <ja...@cominvent.com> 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 <ab...@getopt.org>:
>>
>>
>> On 16 Sep 2019, at 19:38, Yonik Seeley <ys...@gmail.com> 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)
>
Re: Notes from the committers' meeting at Activate 2019
Posted by Gus Heck <gu...@gmail.com>.
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 <ja...@cominvent.com> 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 <ab...@getopt.org>:
>
>
> On 16 Sep 2019, at 19:38, Yonik Seeley <ys...@gmail.com> 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)
Re: Notes from the committers' meeting at Activate 2019
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <ab...@getopt.org>:
>
>
>> On 16 Sep 2019, at 19:38, Yonik Seeley <yseeley@gmail.com <ma...@gmail.com>> 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
>
Re: Notes from the committers' meeting at Activate 2019
Posted by Andrzej Białecki <ab...@getopt.org>.
> On 16 Sep 2019, at 19:38, Yonik Seeley <ys...@gmail.com> 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
Re: Notes from the committers' meeting at Activate 2019
Posted by Yonik Seeley <ys...@gmail.com>.
> - 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
Re: Notes from the committers' meeting at Activate 2019
Posted by Andrzej Białecki <ab...@getopt.org>.
> On 16 Sep 2019, at 17:55, Ishan Chattopadhyaya <ic...@gmail.com> 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 <ab...@getopt.org> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Notes from the committers' meeting at Activate 2019
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
> 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 <ab...@getopt.org> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org