Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Before GitHub

lucumr.pocoo.org

Post reply on HN
Print view View original

71–80 of 255 posts

Re: Before GitHub

#71

Post by bombcar »

mbreese wrote: post #62
bombcar wrote: post #46

Earlier quoted context omitted.

Bugzilla was relatively painless to setup but it already had a bit of the Jira going on - in that it had SO MANY OPTIONS! I remember being interested in MantisBT and a few others (Launchpad for BZR?) mainly because it seemed they made a bunch of decisions for me.

It's a bit fuzzy, but what I remember was getting it running was painless -- but there was a ton of effort in getting it configured. In retrospect, it was probably the flexibility of projects like Bugzilla that heralded the "opinionated" approaches to software that followed. In many ways software also follows the patterns of the language they are written in . Bugzilla was written in Perl, so of course there is more t…

It's fun when you find these various things still in the wild - they're all still out there!

https://dwarffortressbugtracker.com/my_view_page.php

Re: Before GitHub

#72

Post by _-_-__-_-_- »

pdonis wrote: post #64
bsimpson wrote: post #20

I think I was one of the first people to try Flask. I learned Python so I could take advantage of AppEngine for free and easy modern hosting, which put me in the right spot when Flask launched. I've long been an admirer of Armin's, and recognized his domain before I clicked the link. As he points out, in those days, you didn't default to GitHub. His post is a response to Mitchell's, from just a few hours ago. I'm imp…

> His post is a response to Mitchell's, from just a few hours ago. Is there a link to Mitchell's post somewhere? I can't find one in the article.

https://mitchellh.com/writing/ghostty-leaving-github

Re: Before GitHub

#75

Post by swader999 »

MeetingsBrowser wrote: post #43
conartist6 wrote: post #29

I'm working pretty hard on building what comes after Github, but I'm going full-tilt boogie and trying to also work out what comes after Git. I'd love to have a longer conversation with you about how we can seed a better system, because on the off chance I'm successful I have a once-in-a-generation opportunity to fix past mistakes.

Your username is con artist lol

Maybe he likes a challenge?

Re: Before GitHub

#76

Post by conartist6 »

_-_-__-_-_- wrote: post #73
conartist6 wrote: post #53

Earlier quoted context omitted.

Yes, Hi! I'm Conrad.

and also a con artist?

I'd say a code artist, more commonly called a hacker. https://paulgraham.com/hp.html

To be clear for the past five years I've done nothing but write OSS code (https://github.com/conartist6) while sharing pretty much all my engineering thoughts on a public Discord server (https://discord.gg/NfMNyYN6cX), so I'm not very worried at all that a person determined to find out would be unable to tell if I'm legit. You just can't fake 20,000 hours worth of public toil.

Re: Before GitHub

#77

Post by prima-facie »

kelnos wrote: post #56
prima-facie wrote: post #50

Smaller, decentralised forges actually make lots of sense from a digital sovereignty point of view. Over reliance on a single instance like GitHub is not healthy in the long run. The issue they would have to solve is federation.

Yeah, federation is really the sticky bit. It's very frustrating for people to have to create yet another account in order to file an issue or submit a pull request. And on top of that, spam is a huge issue. We've progressively further and further locked down new accounts on gitlab.xfce.org because the spam situation has just gotten so bad. We actually don't allow new "native" account creation at this point, and ask…

Oh we have a neat solution for that. Just give us your government issued id! I'm joking of course.

Thank you for maintaining Xfce! It's the best de around.

Re: Before GitHub

#78

Post by deepsun »

And not a single mention of GitLab. I remember it was a pretty serious contender, sometimes leader, strange that author doesn't mention it.

Re: Before GitHub

#79

Post by thayne »

wps wrote: post #21

I am still so salty that Git won out for the average project over Fossil. Sure Git has some performance advantages for massive codebases like the Linux Kernel, but the vast majority of projects will never run into performance limits from their VCS. Fossil’s internal tools (wiki, forum, tickets , etc) are just so useful to have versioned with your code in one file. I use Fossil for all my freelance work and it so easi…

Part of the problem is that fossil is very opinionated. It's great if your development flow is similar to that of the sqlite team. But it is very difficult to get it to work for other workflows. And in particular, fossil is designed for use by small teams and isn't really designed to be used by large organizations. This is even explicitly mentioned in the "Fossil versus Git" page (https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki)

Re: Before GitHub

#80

Post by thayne »

wps wrote: post #65
PunchyHamster wrote: post #58

Earlier quoted context omitted.

You can (and people did) do same kind of tooling based off git protocol and storage. Hell, even one for distributed code reviews. It just... never was something majority actually want so they didn't really get any traction. Issues wise you also get few nasty cases where you really do not want to keep it with project, like having clients send a bunch of screenshots or even videos of triggering some bugs can grow stora…

Those screenshots and videos are taking up space SOMEWHERE, whether it be your inbox or your filesystem, why not have them as unversioned artifacts in your db? (Fossil supports this). Of course if you have multiple people working on it and many assets, other solutions would be better (shared cloud drives, etc). But for my use case of a storing textual information only (and perhaps a demo video, which many Git users o…

> Those screenshots and videos are taking up space SOMEWHERE,

Sure but there is a big difference between being stored once (modulo backups) on a central server, and every developer needing to download all the resources for every issue and the entire wiki in order to work on the code at all. It works fine for sqlite, because they only have a handful of developers, so it's not a big deal for them each to have their own local copy of everything. But having to download GBs of issue and wiki data in order to make a pull request (however that would work with fossil) or otherwise contribute is a significant barrier to entry.

Post reply on HN