8 ms·

GCC 6.3 Released

129 points by edelsohn 10y ago

pawadu 10y ago
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.
- _joel 10y ago
  Care to highlight what issues you've had with their CVS system?
  - pawadu 10y ago
    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")
    - wyldfire 10y ago
      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.
      - e40 10y ago
        Github was possible because git won.
        pawadu 10y ago
        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.
        wyldfire 10y ago
        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.
        babuskov 10y ago
        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.
        e40 10y ago
        I started using Git before ever hearing about Github.
        sedachv 10y ago
        In 2007 darcs was still popular for a lot of Free Software projects. 2008 is when I noticed people starting to migrate to git.
        sanxiyn 10y ago
        This matches my experience. I switched everything from SVN to Mercurial, and when I grudgingly switched to Git the only reason was GitHub.
        ksherlock 10y ago
        Github bitbucket (2008) and Kiln (2009) both started as Hg. Git hadn't yet won when GitHub started.
        alblue 10y ago
        Atlassian bought BitBucket, not GitHub.
        SEJeff 10y ago
        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.
        cesarb 10y ago
        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).
        SEJeff 10y ago
        Sure, and I said relatively unchanged compared to bzr. Looking up in bzr, the ondisk format changed several times in incompatible ways.
        gioele 10y ago
        > 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.
      - geezerjay 10y ago
        > 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.
    - sigzero 10y ago
      You didn't answer the question. Instead you gave a list of things on why you think git is better.
    - Diederich 10y ago
      Agreed on all points, though that's not exactly the question that was asked.
    - jprzybyl 10y ago
      > 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_engineering/ https://www.openbsd.org/papers/asiabsdcon2009-release_engine... Ted Unangst's blog, email: http://www.tedunangst.com/flak/post/branchless-development http://www.tedunangst.com/flak/post/branchless-development https://marc.info/?l=openbsd-misc&m=134419365218558&w=2 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.)
- davexunit 10y ago
  What is the difference between serving tarballs from ftp.gnu.org vs. savannah.gnu.org?
- throwaway30001 10y ago
  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.
  - SEJeff 10y ago
    Yes you can, you simply put something akin to: Fixes #42 Where the issue is number 42.
    - 4ad 10y ago
      Magic plain text syntax is the worst.
      - SEJeff 10y ago
        And by magic you mean not well documented, right? https://help.github.com/articles/autolinked-references-and-urls/#issues-and-pull-requests https://help.github.com/articles/autolinked-references-and-u... https://github.com/blog/957-introducing-issue-mentions https://github.com/blog/957-introducing-issue-mentions https://help.github.com/articles/closing-issues-via-commit-messages/ https://help.github.com/articles/closing-issues-via-commit-m...
        4ad 10y ago
        Being documented doesn't make it a good idea.
      - feisuzhu 10y ago
        Why？
- dispose13432 10y ago
  >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
  - deleted 10y ago
    [deleted]
  - Someone 10y ago
    https://gitlab.com/gitlab-org/gitlab-ce/ 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.
    - rekado 10y ago
      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.
    - dispose13432 10y ago
      Oops, but it's free anyways.
  - ramshorns 10y ago
    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.html https://www.gnu.org/software/repo-criteria-evaluation.html https://www.gnu.org/software/repo-criteria-evaluation.html
    - dispose13432 10y ago
      > 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
TorKlingberg 10y ago
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&resolution=FIXED&target_milestone=6.3 https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED...
- deleted 10y ago
  [deleted]

129 points by edelsohn 10y ago

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.

_joel 10y ago
Care to highlight what issues you've had with their CVS system?
- pawadu 10y ago
  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")
  - wyldfire 10y ago
    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.
    - e40 10y ago
      Github was possible because git won.
      - pawadu 10y ago
        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.
      - wyldfire 10y ago
        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.
        babuskov 10y ago
        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.
        e40 10y ago
        I started using Git before ever hearing about Github.
        sedachv 10y ago
        In 2007 darcs was still popular for a lot of Free Software projects. 2008 is when I noticed people starting to migrate to git.
        sanxiyn 10y ago
        This matches my experience. I switched everything from SVN to Mercurial, and when I grudgingly switched to Git the only reason was GitHub.
      - ksherlock 10y ago
        Github bitbucket (2008) and Kiln (2009) both started as Hg. Git hadn't yet won when GitHub started.
        alblue 10y ago
        Atlassian bought BitBucket, not GitHub.
      - SEJeff 10y ago
        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.
        cesarb 10y ago
        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).
        SEJeff 10y ago
        Sure, and I said relatively unchanged compared to bzr. Looking up in bzr, the ondisk format changed several times in incompatible ways.
        gioele 10y ago
        > 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.
    - geezerjay 10y ago
      > 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.
  - sigzero 10y ago
    You didn't answer the question. Instead you gave a list of things on why you think git is better.
  - Diederich 10y ago
    Agreed on all points, though that's not exactly the question that was asked.
  - jprzybyl 10y ago
    > 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_engineering/ https://www.openbsd.org/papers/asiabsdcon2009-release_engine... Ted Unangst's blog, email: http://www.tedunangst.com/flak/post/branchless-development http://www.tedunangst.com/flak/post/branchless-development https://marc.info/?l=openbsd-misc&m=134419365218558&w=2 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.)
davexunit 10y ago
What is the difference between serving tarballs from ftp.gnu.org vs. savannah.gnu.org?
throwaway30001 10y ago
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.
- SEJeff 10y ago
  Yes you can, you simply put something akin to: Fixes #42 Where the issue is number 42.
  - 4ad 10y ago
    Magic plain text syntax is the worst.
    - SEJeff 10y ago
      And by magic you mean not well documented, right? https://help.github.com/articles/autolinked-references-and-urls/#issues-and-pull-requests https://help.github.com/articles/autolinked-references-and-u... https://github.com/blog/957-introducing-issue-mentions https://github.com/blog/957-introducing-issue-mentions https://help.github.com/articles/closing-issues-via-commit-messages/ https://help.github.com/articles/closing-issues-via-commit-m...
      - 4ad 10y ago
        Being documented doesn't make it a good idea.
    - feisuzhu 10y ago
      Why？
dispose13432 10y ago
>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
- deleted 10y ago
  [deleted]
- Someone 10y ago
  https://gitlab.com/gitlab-org/gitlab-ce/ 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.
  - rekado 10y ago
    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.
  - dispose13432 10y ago
    Oops, but it's free anyways.
- ramshorns 10y ago
  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.html https://www.gnu.org/software/repo-criteria-evaluation.html https://www.gnu.org/software/repo-criteria-evaluation.html
  - dispose13432 10y ago
    > 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

TorKlingberg 10y ago

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&resolution=FIXED&target_milestone=6.3 https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED...

deleted 10y ago
[deleted]