181–190 of 253 posts
Earlier quoted context omitted.
Why would it?
A lot of package manager tools download their packages from Github. If you happened to be refreshing your dependencies at the time, or doing a clean build, then you'd be SOL.
Earlier quoted context omitted.
Yeah I know I'll be on vacation for a long while!
Hope it will be on the moon or in a nuclear shelter. Otherwise all that fallout may ruin your trip.
Earlier quoted context omitted.
I'd prefer it just for searchability. Good luck finding anything online called "maintainer".
I think he was excgarating the issue a bit. Your logic is sound
I commit to re-use this as often as possible!
http://www.urbandictionary.com/define.php?term=Excgarated
An inspiring new word invented by a redditor on March 23, 2014. The redditor was actually trying to spell exaggerated. This word was misspelled so horribly that when it was googled the only thing that came up was a link to the comment itself.
Earlier quoted context omitted.
I keep meaning to dig into Fossil (SQLite's VCS/Project Management system), but I have no faith I could convince a team to use it. Another model to look at is Trac, which had pretty extensive integration with SVN and integrated (ie, cross-linked) issue tracking and wiki, and stored all the data and change history in a svn repository.
> I keep meaning to dig into Fossil, but I have no faith I could convince a team to use it. Developer or Fossil and SQLite here: I agree. In my experience, you'd have better luck convincing the team to switch from vi to emacs. For all its many and well-documented faults, the Git/GitHub paradigm is what people want to use because it is what they are familiar with. All the same, I intend to keep right on using Fossil,…
Earlier quoted context omitted.
The problem isn't the VCS part so much as all the code review/project management features of Github. I seem to remember there was a decentralized VCS which included issue tracking besides commits, but it never was mainstream.
the linux kernel development works just fine w/o github.
It's not exactly less of a point of failure.
Earlier quoted context omitted.
> bored developers Bored? Git's a distributed version control system, so no excuses. Get back to work! But in all seriousness I kind of wish GitHub provided a way to mirror things like issues and PRs so you never have to be fully reliant on one service. Not being able to read these really does make it impossible to get work done offline.
I'm of the impression that issues and PRs are all accessible via an API. What more should they do?
How about storing issues and PRs in the actual git repository? They should index them for the UI, sure, but the source of truth should be a branch of the git repo just like it is with gh-pages. It should be possible to file a new issue by committing a markdown file to the correct branch and pushing it to Github. Their hub command line tool and their own client could facilitate adding all the correct metadata. This would allow people to work while Github.com is offline and synchronize everything once the service outage is over.
If you have access to a distributed database that is already the best available for manual conflict resolution, why wouldn't you want to use it to store this kind of data? A Github outage is like a partition when you think about it from a distributed db perspective, so treat it like an individual node died and still allow reads/writes to the rest of the cluster that can be merged back once the node comes back online.
Earlier quoted context omitted.
> bored developers Bored? Git's a distributed version control system, so no excuses. Get back to work! But in all seriousness I kind of wish GitHub provided a way to mirror things like issues and PRs so you never have to be fully reliant on one service. Not being able to read these really does make it impossible to get work done offline.
GitLab.com has repository mirroring https://docs.gitlab.com/ee/workflow/repository_mirroring.htm... (this will soon be a paid account feature) It doesn't mirror issues and PRs but it can do a one time import of them https://docs.gitlab.com/ee/workflow/importing/import_project...
Earlier quoted context omitted.
The problem isn't the VCS part so much as all the code review/project management features of Github. I seem to remember there was a decentralized VCS which included issue tracking besides commits, but it never was mainstream.
the linux kernel development works just fine w/o github.
Earlier quoted context omitted.
But they want you to Rely on Github... if they could find away to make Git only work with Github they would in a heart bet. Github is not a open source company, it is not really even a supporter of free software IMO they are a danger to free software for this very reason. They are following the old school Microsoft model of Embrace and Extend... I am waiting to see if they can extinguish,
Contentless, illogical mince. GitHub clearly contributes a fair bit to open source - not only their own projects, but the free hosting for open source projects. You have no basis for this accusation, and frankly we are all stupider for having read it.
I love it, and it's perfect for when you want to say something witty like FUD or D&D, but can't justify it. Now with CIM, I can!
Earlier quoted context omitted.
DISCLAIMER: I work for GitLab. We have a feature to replicate GitLab to different locations (EEP). We call it "Geo", which stands for "Geographical Replication". Part of the "Geo" effort is Disaster Recovery which is under heavily development. We want with Disaster Recovery to be able to reliably promote any Secondary node to a Primary, so if your US datacenter melts down under a nuclear war, you can start working wi…
If your US datacenter melts down under a nuclear war, I can guarantee that none of your devs will give a damn about contributing to the code base. You might want to modify your scenarios.
