GCC 6.3 Released(gcc.gnu.org)
gcc.gnu.org
GCC 6.3 Released
https://gcc.gnu.org/ml/gcc/2016-12/msg00132.html
45 comments
I couln't find a changelog, but there is a list of fixed bugs in the tracker: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED...
[deleted]
This release is available from the FTP servers listed at:
I wish GNU people could clean up Savannah and use it as their main distribution point.
Well, at least they are not OpenBSD with their ancient CVS system.
I wish GNU people could clean up Savannah and use it as their main distribution point.
Well, at least they are not OpenBSD with their ancient CVS system.
I had to use their "ancient CVS system" once in order to submit a patch. As usual with OpenBSD, documentation was superb and the setup was very user friendly.
To this day, the navigation in their OpenCVS web interface beats most of the alternatives.
Really, learning git and GitHub requires much more effort. Heck, you can't even attach a PR to an open GitHub issue. That's progress, I guess.
To this day, the navigation in their OpenCVS web interface beats most of the alternatives.
Really, learning git and GitHub requires much more effort. Heck, you can't even attach a PR to an open GitHub issue. That's progress, I guess.
Yes you can, you simply put something akin to:
Fixes #42
Where the issue is number 42.
Fixes #42
Where the issue is number 42.
Magic plain text syntax is the worst.
And by magic you mean not well documented, right?
https://help.github.com/articles/autolinked-references-and-u...
https://github.com/blog/957-introducing-issue-mentions
https://help.github.com/articles/closing-issues-via-commit-m...
https://help.github.com/articles/autolinked-references-and-u...
https://github.com/blog/957-introducing-issue-mentions
https://help.github.com/articles/closing-issues-via-commit-m...
Being documented doesn't make it a good idea.
Why？
What is the difference between serving tarballs from ftp.gnu.org vs. savannah.gnu.org?
>I wish GNU people could clean up Savannah and use it as their main distribution point.
Why don't they use GitLab CE? It's under the GPL
Why don't they use GitLab CE? It's under the GPL
GNU grades hosting services based on different sets of criteria. GitLab gets a C, "acceptable hosting for a GNU package", but not "good enough to recommend" because the JavaScript on the website is free but doesn't work with analyzers like LibreJS, and because GitLab doesn't discourage bad licensing practices. GNU Savannah, of course, gets an A.
https://www.gnu.org/software/repo-criteria.html
https://www.gnu.org/software/repo-criteria-evaluation.html
https://www.gnu.org/software/repo-criteria.html
https://www.gnu.org/software/repo-criteria-evaluation.html
> the JavaScript on the website is free but doesn't work with analyzers like LibreJS
How hard would it be for GNU to maintain a fork of that instead of maintaining their own codebase?
>GitLab doesn't discourage bad licensing practices
If they host it, they can discourage whatever they want
How hard would it be for GNU to maintain a fork of that instead of maintaining their own codebase?
>GitLab doesn't discourage bad licensing practices
If they host it, they can discourage whatever they want
yeah, their complaints against gitlab seems like nitpicking.
If the gitlab people could fix these minor issues and receive the blessing of RMS I think they could get some exposure outside their usual market.
(whether that gets them more paying costumers is a whole different discussion)
If the gitlab people could fix these minor issues and receive the blessing of RMS I think they could get some exposure outside their usual market.
(whether that gets them more paying costumers is a whole different discussion)
> If the gitlab people could fix these minor issues
Sorry, dropping in here while working on our release of today. Could you clarify what issues?
We're always excited to help projects move to GitLab.
Sorry, dropping in here while working on our release of today. Could you clarify what issues?
We're always excited to help projects move to GitLab.
From the GNU website:
---
Things that prevent GitLab from moving up to the next grade, B:
I think at least B2 is a reasonable request, although this may have already been fixed (sorry, I use gitlab but barely visit the site itself).
---
Things that prevent GitLab from moving up to the next grade, B:
All JavaScript code served to the client is free, but does not work with LibreJS enabled. (B0)
Encourages bad licensing practice, including no license; failure to state the license on each source file; and failure to say which GPL versions apply. (B2)
I think at least B2 is a reasonable request, although this may have already been fixed (sorry, I use gitlab but barely visit the site itself).
Good point. I was confusing GitLab.com the hosting service with GitLab CE the server software, which they could run an instance of.
Slightly off topic, but I find it interesting that they find logging people more ethical than calling Linux the conventional way over Gnu/Linux.
Yeah, thats RMS in a nutshell for you:
Avoids saying “Linux” without “GNU” when referring to GNU/Linux. (A8)
https://gitlab.com/gitlab-org/gitlab-ce/:
"GitLab Community Edition (CE) is available freely under the MIT Expat license."
I don't see GPL mentioned there.
"GitLab Community Edition (CE) is available freely under the MIT Expat license."
I don't see GPL mentioned there.
You are correct. To avoid a common misunderstanding I'd like to note that GNU people have no problem using software that has been released under the Expat license. It doesn't have to be copyleft software to be free/libre.
Oops, but it's free anyways.
[deleted]
Care to highlight what issues you've had with their CVS system?
A tool like git could make operations such as branching and merging easier, and allowing developers to collaborate more. It also has a global revision identifier (instead of file based revisions) and signed commits which may increase security.
Also, git on the server seems to use less resources (which is one of the reasons git "won")
Also, git on the server seems to use less resources (which is one of the reasons git "won")
> A tool like git could make operations such as branching and merging easier
OpenBSD has been traditionally anti-branch.
Theo de Raadt's 2009 presentation: https://www.openbsd.org/papers/asiabsdcon2009-release_engine...
Ted Unangst's blog, email: http://www.tedunangst.com/flak/post/branchless-development https://marc.info/?l=openbsd-misc&m=134419365218558&w=2
Basically, it's to make all OpenBSD developers participate in the release process. There's no dev and stable team - everyone is in the same tree, makes breaking changes early, spends months stabilizing. CVS helps force developers to participate, because branches can't exist for long before the resulting merge is too painful to be worth it.
Although, they are careful to say that, just because it works for them, doesn't mean it will work for you. As well, your other points are still valid. (My personal gripe is that CVS over the net is so slow that I have to use an external tool like CVSync.)
OpenBSD has been traditionally anti-branch.
Theo de Raadt's 2009 presentation: https://www.openbsd.org/papers/asiabsdcon2009-release_engine...
Ted Unangst's blog, email: http://www.tedunangst.com/flak/post/branchless-development https://marc.info/?l=openbsd-misc&m=134419365218558&w=2
Basically, it's to make all OpenBSD developers participate in the release process. There's no dev and stable team - everyone is in the same tree, makes breaking changes early, spends months stabilizing. CVS helps force developers to participate, because branches can't exist for long before the resulting merge is too painful to be worth it.
Although, they are careful to say that, just because it works for them, doesn't mean it will work for you. As well, your other points are still valid. (My personal gripe is that CVS over the net is so slow that I have to use an external tool like CVSync.)
Agreed on all points, though that's not exactly the question that was asked.
You didn't answer the question. Instead you gave a list of things on why you think git is better.
IMO git won due to github more than anything else. They arrived first, had satisfactory terms for open source projects and didn't do a bad job.
> IMO git won due to github more than anything else.
You're reversing the causes and consequences.
Git was awesome from the start, and asn an over-night success due to linux.
Github's contribution, and role in git's success, was only one: providing a free hosting service that presented a usable and user-friendly alternative to sourceforge.
There are plenty of hosting companies that support Git, and some even supported competing decentralized version control systems from the start. Yet, none of them worked so well as git.
You're reversing the causes and consequences.
Git was awesome from the start, and asn an over-night success due to linux.
Github's contribution, and role in git's success, was only one: providing a free hosting service that presented a usable and user-friendly alternative to sourceforge.
There are plenty of hosting companies that support Git, and some even supported competing decentralized version control systems from the start. Yet, none of them worked so well as git.
Github was possible because git won.
I disagree. Github arrived in 2008, soon after many DVCS options arrived. Mercurial and git were developed at very near the same time in 2005, Bazaar was developed around then too. I don't believe that git had anywhere near the market share back in 2008 that it enjoys now.
When github arrived, git's biggest win was the kernel. But that was kinda a given if you consider its genesis. Granted, it's a noteworthy project that helps prove git's scaling capability. But IMO git didn't win until years later when folks who had adopted the other DVCS engines started switching to git.
When github arrived, git's biggest win was the kernel. But that was kinda a given if you consider its genesis. Granted, it's a noteworthy project that helps prove git's scaling capability. But IMO git didn't win until years later when folks who had adopted the other DVCS engines started switching to git.
Don't know about the rest, but I switched from SVN to git before I even heard of Github for my personal project and also in the company I was CTO at the time.
Two things were decisive: being able to commit and browse the whole history while offline and the fact that my main dev machine was Linux so it worked faster than anything else.
Two things were decisive: being able to commit and browse the whole history while offline and the fact that my main dev machine was Linux so it worked faster than anything else.
I started using Git before ever hearing about Github.
This matches my experience. I switched everything from SVN to Mercurial, and when I grudgingly switched to Git the only reason was GitHub.
In 2007 darcs was still popular for a lot of Free Software projects. 2008 is when I noticed people starting to migrate to git.
And git won because hands down it was the fastest and most flexible, albeit most horrible UX. Also unlike something like say bzr, the core on disk git format has stayed relatively unchanged since it was first written. The architecture is simply the best in git compared to most other vcs software.
Actually, there was one big disk format change early in git history: the object id changed from the SHA1 of the compressed object to the SHA1 of the uncompressed object. All three projects using git back then (Linux, sparse, and git itself) had to convert to the new format (since the object ids changed, every tree and commit object had to be rewritten).
Sure, and I said relatively unchanged compared to bzr. Looking up in bzr, the ondisk format changed several times in incompatible ways.
> Sure, and I said relatively unchanged compared to bzr. Looking up in bzr, the ondisk format changed several times in incompatible ways.
But bzr always had the ability to read and write repositories written using older formats. Each on-disk repository format is implemented as a set of separate Python classes, all exposing the same interface.
Git thought it could do without a "repository format version identifier" and a strategy for multiple on-disk formats until version 2.7 (2015). Bzr had everything well planned out since the beginning.
But bzr always had the ability to read and write repositories written using older formats. Each on-disk repository format is implemented as a set of separate Python classes, all exposing the same interface.
Git thought it could do without a "repository format version identifier" and a strategy for multiple on-disk formats until version 2.7 (2015). Bzr had everything well planned out since the beginning.
Although this week I learned that github won because some VC had just too much money to throw around :)
Jokes aside, github won because - unlike sourceforge and gitorious - their web interface did not suck.
Jokes aside, github won because - unlike sourceforge and gitorious - their web interface did not suck.