Hacker News Reader

> 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.

Seems like this open letter is exactly the kind of thing a community manager should have gotten on tho.

This. I'm a big fan of Github, but it bothers me that this single service is the centerpiece of most OSS projects. We see it every time Github goes down and virtually nobody can be productive anymore. I hope to see a version control system on top of IPFS some day.

Ironically, git itself is decentralized. More effort should go into decentralized software architectures, especially in the current security climate where having a central point of failure is like having a virtual bull's eye for bad guys. There's no reason you couldn't have a decentralized issue tracker for example.

> If issue tracking and code reviews were based on a common, distributed system like git itself

There you go: https://github.com/google/git-appraise

Suckless have discussed this several times and have fallen back to an email mailing list.

http://lists.suckless.org/dev/1201/index.html#msg10574

Last one proposed by someone: http://lists.suckless.org/dev/1504/26210.html

The problem with mailing lists is that patches and bug reports get forgotten.

Well that's a problem with the developers.

Amount of times I've posted a bug on a mailing list and a core developer doesn't care to respond is unbelievable. Here is a recent one: http://lists.alpinelinux.org/alpine-user/0042.html

>We need world class, modern, distributed bug tracking now

Distributed is the key word. Blockchain/Bitcoin (not withstanding the hurtful politics ongoing at present) has shown the way, and ideally most shared/social things should work in a distributed, trust-less environment in future. Including Social networks and Search Engines.

So it is quite natural, that OSS developers can pave the way for shared/distributed source control (a protocol on top of GIT. Just like HTTP is over TCP).

Just to clarify, I don't hate github. But it sort of obscures the beauty/advancement that is GIT, over previous version control softwares. Wonder what does the creator Linus think of this?

Well, for one he doesn't like GitHub pull requests. ;)

https://github.com/torvalds/linux/pull/17#issuecomment-56546...

> We need world class, modern, distributed bug tracking now.

Why distributed? You need a central place to report bugs and track them to ensure they’re not duplicated everywhere.

I am not Michael Bayer (but I hope to be more like him someday)... that said, what I think he means or could mean is that issues would be distributed along with the repo. Maybe something like a git log for issues that are attached to and/or part of the repo itself.

Thinking about it, something like this would be sweet. I would immediately have a snap shot of things that might go boom when I run said software. eta: Instead, I have to go dig through github itself, which is slow compared to greping through a git log.

Problem is for that system you need per-user authentication mechanisms to verify the interacting party in a bug report. If you can't do that, people can impersonate project members and you're going to have a bad time. Centralized issue tracking is not winning because of implementation details, its winning because you need some central authority to verify people are real and who they say they are.

You would have to sign off every message in a git log tree with a personally authenticated gpg key that can be found in a public keyserver everyone trusts.

All of those issues would apply to DVCS as well, I can clone any project and commit whatever crap I want to it, I just can't push to the main repo of the project.

Distributed issue tracking would use a similar pull model, but in reality wouldn't normally need people to be "cloning" it or anything like that; more realistically, a project would have just one place that is the "official" bug tracker just like they do a git repo now. But with "distributed", you can now have read-only mirrors of it elsewhere, you can have alternative GUIs that can push to the "official" repo as long as you have an account on that "official" host (which may as well be github), etc. It's not as important that it's truly "distributed", more that this is a set of issues that as a body of information about a project can and does live in many places, just like the version control does, just like the mailing list does, just like the IRC logs do. Right now issue tracking is like none of these other things.

You've described Fossil.

http://fossil-scm.org/index.html/doc/trunk/www/index.wiki

yes, fossil, you need to get me past this:

http://fossil-scm.org/index.html/dir?ci=acbee54e8ba8a3bd&nam...

I'm talking about a portable issue tracker format that ideally uses something like git as its transport (but note: this does not mean that the issue database would travel along with the application's source code! That might be nice as an option but not by design). command-line and web-based front ends can then refer to it. Fossil, OTOH, looks like a huge monolithic web application / version control system / issue tracker / kitchen sink written in very hard-coded C.

Looking through some docs, Fossil is anti-git and it claims its own DVCS is a great improvement over git: http://fossil-scm.org/index.html/doc/trunk/www/quotes.wiki. Because Fossil has every possible feature packed all into one monolithic executable, rather than relying upon existing systems like diff, patch, etc. this means Fossil is "the opposite of bloat": http://fossil-scm.org/index.html/doc/trunk/www/qandc.wiki (in fact that is the opposite of the opposite of bloat....)

Bugs Everywhere was one of the leading distributed bug trackers. They don't seem to be gaining any traction unfortunately.

http://www.bugseverywhere.org/

Also, no GUI emerged. This is what github gives you on top of git.

Why distributed version control? You need a central place to pull from and push to, to ensure that forks and patches are not duplicated everywhere... ;)

I wrote a little bit about this two years ago: https://sny.no/2014/04/dbts

There’s not necessarily an antagonism between distributed and centralised in this case. You can still have a centralised frontend such as Github Issues, backed by a versioned and distributed backend using i.e. git.

You mean like GitLab?

GitLab is still centralised (whomever is hosting…), not distributed.

True.

How about improving Gittorrent?

Maybe you're interested in this feature request https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 to implement cross-server (federated) merge requests.