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 <jan....@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 <gus.h...@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 <markrmil...@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 <markrmil...@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 <ans...@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_luc...@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-unsubscr...@lucene.apache.org >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>> >>>> >>>> >>>> -- >>>> Anshum Gupta >>> >>> >>> >>> -- >>> - Mark >>> >>> http://about.me/markrmiller >> >> -- >> - Mark >> >> http://about.me/markrmiller > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
