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 <erickerick...@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 <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 > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
