Live data from Hacker News

The single most important criteria when replacing GitHub

joeyh.name

81–90 of 135 posts

Re: The single most important criteria when replacing GitHub

#81

I’ve always thought of version control systems and issue trackers as separate products. GitHub just happens to implement them both in one place. As others are alluding to in the comments, I’m highly skeptical of coupling the issue tracker and other non-VCS features with git. A far better solution would be to keep them decoupled, but easily pluggable and extendable. In fact, this is basically the status quo with any i…

> I’ve always thought of version control systems and issue trackers as separate products.

Agreed, but coupling has extreme benefits. No matter how stringent you are on your commit message requirements, you'll never capture the scope of a code change as well as the originating issue.

They may be separate products, but the need for a cross-vendor common interface/implementation persists. Also, the ability to take your ball and play elsewhere is required too. If a git-like approach were taken towards issue management and all of these platforms could implement/use it, nobody would ask to piggy back on git. Then again, you can apply this same discussion to any form of structured, persisted digital content...nobody wants to be locked in. Just so happens that the code part happens to have an unencumbered implementation that others have embraced.

Re: The single most important criteria when replacing GitHub

#82

Earlier quoted context omitted.

Couldn't agree more. It seems naive to think that source control would be a good system for the kind of operations performed in issue tracking

Issue tracking is all about managing changes to objects (issues) made over time by multiple people from different machines. Seems like a perfect case for VCS to me.

A VCS might be a good storage location for these 'objects', but it certainly doesn't provide the structure to manage them.

Re: The single most important criteria when replacing GitHub

#84

I’ve always thought of version control systems and issue trackers as separate products. GitHub just happens to implement them both in one place. As others are alluding to in the comments, I’m highly skeptical of coupling the issue tracker and other non-VCS features with git. A far better solution would be to keep them decoupled, but easily pluggable and extendable. In fact, this is basically the status quo with any i…

I feel like the HN community fails repeatedly to really grok this concept. They focus on the negatives of having a single dominant player for a service (with worries about monopolistic practices and stagnation), but completely ignore WHY these single providers become dominant. There are HUGE network-effect benefits to having a single dominant provider. Right now, if I am looking for a code library, I pretty much only…

And this is exactly why it's wrong.

Re: The single most important criteria when replacing GitHub

#86
post #2

This reminds me Fossil SCM. The bug tracking and wiki are part of the distributed version control system. https://en.wikipedia.org/wiki/Fossil_(software)

I had a job once where we used Lotus Notes. I'll take extensibility over integration any day.

But you had the unlimited power of LotusScript(tm)(c)(r) at your fingertips to add all those niche features that the Notes developers don't care about!

You know, crazy things like forwarding calendar invites as calendar invites instead of emails, deleting emails older than X days, etc.

/s

Re: The single most important criteria when replacing GitHub

#87
post #54

Even if I ended up migrating from github, I would still look for a centralized instance. Why ? The price for one migration in a few years is not a big deal compare to self hosting, which is a human resource hog for small entities. I have more important things to do than to deal with deploy, configure, maintain, document, secure, and test my own instance. I really don't want to admin one more server just for that. I d…

I think a properly decentralized system (basically everything Github was except stored inside or alongside the repo) solves the self-hosting headaches also -- If everyone has the issue queue, kanban board, yadda, CI results, etc. on their laptops you don't have to host and administer some app to do any of those things, only a dumb storage for backup and sync and services like CI that support those things in any kind…

And accounts.

Re: The single most important criteria when replacing GitHub

#88

I’ve always thought of version control systems and issue trackers as separate products. GitHub just happens to implement them both in one place. As others are alluding to in the comments, I’m highly skeptical of coupling the issue tracker and other non-VCS features with git. A far better solution would be to keep them decoupled, but easily pluggable and extendable. In fact, this is basically the status quo with any i…

> As others are alluding to in the comments, I’m highly skeptical of coupling the issue tracker and other non-VCS features with git.

What do you mean by coupling? Are you talking about what Gitlab Omnibus does by bundling an issue tracker and other web services along with its core git functionality?

If so, you're wrong-- Gitlab's approach helps a busy maintainer get their work done without being hemmed in to a service like Github. The issue tracker's defaults are sane, non-technical users can easily sign up using the other bundled services and communicate using it, and it gets upgraded as a side-effect of upgrading Gitlab itself.

If I had instead used one of your claimed "far better solutions," I'd have spent hours researching issue trackers and installing/configuring one of them. That's time taken away from developing the software I'm housing in Gitlab.

Or, even worse, I'd have asked on the dev list, "what's a good, solied open source issue tracker?" And we'd have bike-shedded for 10x the time.

Re: The single most important criteria when replacing GitHub

#90
post #45

Earlier quoted context omitted.

It works both ways. If you're too lazy to learn a service I chose to host my code, you don't deserve my code. (Sorry to put it harshly, but it's felt like we're all getting a bit spoiled. Especially compared to the old days.) For better or worse, you are the product if you use a centralized, free service. And the only thing keeping those dominant players dominant is the blind loyalty we seem to give freely. It's all…

I use (for example) 50 libraries, and want to submit bug reports and pull requests to all of them over the course of 5 years... and your attitude is "well.. if you don't make 50 accounts you don't deserve it!". Really? And also that's why we have package repositories... npm, nuget, PECL, composer, should i also register on 500 websites just so i can build a website or two? Also, github is free for open-source project…

This is what I like about collaborating on code that still uses mailing lists to collaborate. I already have an account that I can use for every mailing list in existence -- my email account.
Post reply on HN