281–290 of 491 posts
Earlier quoted context omitted.
Absolutely agree! I cannot fathom why people are still actively supporting GitHub. Even if you ignore the ethical reasons, which if you are an open source developer really should suffice, GitLab is better and more customizable in every way. Supporting it benefits yourself and all of the FOSS community.
gitlab.com is dog slow and my code is too important to risk self hosting.
Earlier quoted context omitted.
About number 5. I don't see anyone complaining about anything.
Maybe "complain" is too strong, but he created a GitHub issue –notifying several hundred people– without running ag --version. Heck, he didn't even look at the output of his command. It was immediately obvious to me, from the limited information he provided, that it was a bash alias.
I guess it depends on the project and its contribution guidelines.
Earlier quoted context omitted.
> I normally put a big "[DEPRECATED]" notice at the beginning of the README. Aye. Some folks in the discussion linked to by krschultz complain that "People sometimes don't read the README and -thus- don't notice deprecation warnings.". To them I ask: "What makes you think that those sorts of people will notice anything less than an overlay that prevents them from interacting with the Github UI for that particular rep…
One concern would be around tools that fetch from github automatically. go get for example would need some sort of structured metadata if it wanted to surface an error to a user that a library is deprecated.
Sure. But... like... git doesn't know anything about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would have to modify the contents of the repo, right?
> ...go get for example would need some sort of structured metadata [to do reasonable repo deprecation warnings]
I mean, the JavaScript development community has -collectively- decided on a huge bundle of ad-hoc standards. I bet that it would be trivial for the signatories of the open letter to decide on a tagging mechanism to use in their README files to indicate repo deprecation. Do you disagree?
Earlier quoted context omitted.
An open question is how the community should provide feedback. Trello provides a decent example of how to do it well [1], but GitHub feels like a black box. I've been on GitHub since 2008 and I have been paying every month for years, but other than emailing support I have no idea how to vote for a feature request. My personal pet peeve is not being able to mark a public repo as 'deprecated'. There are a lot of other…
I normally put a big "[DEPRECATED]" notice at the beginning of the README. This normally doesn't go unnoticed. Another good example is harthur's "[UNMAINTAINED]" [1] [1] https://github.com/harthur/brain
We need world class, modern, distributed bug tracking now. If you google around for this technology, a lot of nice ideas, many using git itself as transport, were poking around, and around 2009 they started falling silent. Why? Because GitHub started up and everyone just buzzed over to it like so many moths to a flame, having learned nothing from places like Sourceforge about what happens when 90% of the open source…
> If GitHub is kicking back and sitting on their huge valuations, There is no longer an "if". It's absolutely true that GitHub is cruising at this time. For example: They are more interested in hiring community managers / community "heroes" instead of actual engineers in SF.
Each and every suggestion is a sane and much needed improvement.
I completely agree with some of these suggestions, but it doesn't need all of them. If you really need a heavily-customizable issue tracking system, you can do anything you want in Bugzilla or Jira. Every checkbox, dropdown and mandatory field they add makes GitHub Issues less attractive to those who don't need it. Simplicity is a feature, and it's one that you sacrifice as you make your software more flexible.
Earlier quoted context omitted.
> They're chasing some other goal...whatever it is. I've been puzzled for a while with what github is doing hiring so many social impact employees. https://twitter.com/agelender https://twitter.com/_danilo https://twitter.com/rachelmyers https://twitter.com/nmsanchez https://twitter.com/BiancaCreating https://twitter.com/ammeep https://twitter.com/davystevenson Maybe something more noble than a social coding site?
Maybe something more noble than a social coding site? I doubt it. Github has a reputation problem. I wouldn't put anything sensitive on there, given the attitude github leadership showed about privacy ethics in the Julie Horvath incident.
They seem to think they're too big to fail.
Interesting petition, and I agree with it; but I wonder why are all projects mentioned in the _Signed by_ section based on JavaScript? I know there are other languages involved in some of those projects like C++ and Java in Selenium and PhantomJS but this specific thing in the document makes me believe that only JavaScript developers _(at least the ones using GitHub)_ are more prone to complain than other type of dev…
Earlier quoted context omitted.
One concern would be around tools that fetch from github automatically. go get for example would need some sort of structured metadata if it wanted to surface an error to a user that a library is deprecated.
> One concern would be around tools that fetch from github automatically. Sure. But... like... git doesn't know anything about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would have to modify the contents of the repo, right? > ...go get for example would need some sort of structured metadata [to do reasonable repo deprecation warnings] I mean,…
The people who ask for more proprietary features (or should I say anti-features) in Github are encouraging lock-in inside of Github. Github ought to be a hub. I'd like to emphasize on the hub part as it should be one hub out of many. It should not be the center of the software universe any more than AT&T/IBM/Microsoft/Google/Facebook/Uber.
Earlier quoted context omitted.
> One concern would be around tools that fetch from github automatically. Sure. But... like... git doesn't know anything about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would have to modify the contents of the repo, right? > ...go get for example would need some sort of structured metadata [to do reasonable repo deprecation warnings] I mean,…
I am not your grand parent poster but I fully agree with you and I'd go further than that. The people who ask for more proprietary features (or should I say anti-features) in Github are encouraging lock-in inside of Github. Github ought to be a hub. I'd like to emphasize on the hub part as it should be one hub out of many. It should not be the center of the software universe any more than AT&T/IBM/Microsoft/Google/Fa…
So, I heartily agree that vendor lock-in is bad. [0] However, git doesn't handle mailing lists, or issue trackers, or hands-off repo push access control, or.... So, if you're going to do more than just serving git repos, you're almost certainly going to have to do these things yourself, and you very well might end up doing them in a way that differs from how everyone else is doing them.
I mean, as long as you can get complete exports of the data in the important non-git bits, who cares, right?
[0] I'm STILL mad about how Hangouts turned out.