The fast-export --anonymize item is interesting. I've used a few tools professionally that I've been unable to feasibly report some bugs for, because any time I produce a log file (or whatever) it's filled with file names or email addresses or function names or code snippest or paths or whatever. Or if it's an example file, it contains copyrighted information that one can't just go giving away to 3rd parties.
Had there been some kind of anonymization option, on the other hand, there'd have been no problem. As it is, I just have to produce some hand-wavey bug report, that's as accurate as I can make it - that then presumably gets put on the shelf with all the other random unclassifiable oddities that nobody has time to look at properly. Because they're too busy dealing with the bugs that actually came with data.
(Of course, sometimes the data itself is the problem, and then this wouldn't help. Then other times, the system in question has faulty RAM. This wouldn't help with that either.)
And once again there is a need for a friendly reminder:
If you release a bit of software and wish the audience to pay more attention than they would to any average maintenance releases:
Put something in the title of the release announcement to explain what makes this one special.
Try to do it in a way that makes sense to someone who rarely ever even uses your software.
That seems a trifle petty: Just skimming through the list of updates and I'm already impressed by the content, and I've not even gotten to the fixes yet.
There is no "one-liner" that will capture this, save perhaps something near-linkbaity like "git 2.2.0 - almost a hundred contributors, 20 brand new, with dozens of updates and dozes of fixes! Whew!"
Having said that, the announcement of a point release like this isn't the place to appeal to those who are not git users: This notice is aimed squarely at those who are git users and need to know whether or not they should upgrade.
Marketing communication is all about understanding your market, its segments, and the messaging each segment needs. This announcement isn't for newbies or notbies.
If there is a grain of truth in your comment, then it is that a separate announcement is needed, a more general press release, aimed perhaps at the wider community, to whit:
Team responsible for world's most popular distributed revisioning system announces update
Git, the world's most popular distributed revisioning system, has been updated, according to announcements released this morning to the development community.
The new release features contributions from over 70 contributors, 20 of whom mark their git release debut. This version, dubbed 2.2.0, contains approximately two dozen fixes to the 2.1 release as well as several dozen backwards-compatible new features.
The development team is thrilled and proud of their work and eagerly awaits community feedback.
<Insert standard description of git here>
<Insert list of major git projects here>
<Insert upgrade roadmaps for GitHub and other git-as-a-service providers>
<Insert standard description of revision control here>
<Insert standard "considering switching to git? look here"?>
<Insert standard "new to git? look here">
(All of the above CC-BY-SA, feel free to use as desired.)
> something near-linkbaity like "git 2.2.0 - almost a hundred contributors, 20 brand new, with dozens of updates and dozes of fixes! Whew!"
Titles like that are linkbait when the document linked is not actually worth the hype of the title. Actually descriptive titles like your example are great titles in my opinion, except possibly the last bit with exclamations.
Here's my friendly reminder. If you only pay attention to linkbait headlines and vapid blog content, you're going to have a hard time finding well-written software amidst the sea of well-marketed crap.
There is a fair amount of space between "something in the title of the release announcement to explain what makes this one special" and "linkbait headlines and vapid blog content".
There's a space for both well-written content and well-written ledes.
Gripping ledes with poor quality content are a letdown and tarnish your brand. I've null-routed numerous hosts for persisting in that practice simply so that I don't go there.
Interesting content that's either poorly written or has bad ledes also suffers. I run across these all the fucking time, and to its detriment, the fact that Hacker News relies solely on the original content headline and not a bit of introductory text (Slashdot did and does a far better job in this regard, Reddit's link posts share the failure) makes this site susceptible to the problem. I'll generally click through to comments in search of context before going to the article itself.
Jeff Atwood's got a recent excellent post on a related topic -- getting people to actually read linked articles and avoiding dysfunctional incentivization:
The Windows build is made by the msysGit team (https://msysgit.github.io/), which is a separate team with a chronic lack of manpower.
The Git situation on Windows is somewhat like openssh versus portable openssh, or libressl versus portable libressl: it's originally developed for one system, and a separate project ports it to another system. It's a bit harder for Git on Windows, since Git was written expecting a POSIX system (parts of Git are written in shell or Perl, for instance), and Windows is different enough to give it trouble.
If you want Git on Windows to be more up-to-date, give them a help; I'm sure they'll appreciate it.
Yep, and it's not a surprise. Apple very conservatively updates their open source components. Only because of Shellshock did we get an update to the Bash shell.
Had there been some kind of anonymization option, on the other hand, there'd have been no problem. As it is, I just have to produce some hand-wavey bug report, that's as accurate as I can make it - that then presumably gets put on the shelf with all the other random unclassifiable oddities that nobody has time to look at properly. Because they're too busy dealing with the bugs that actually came with data.
(Of course, sometimes the data itself is the problem, and then this wouldn't help. Then other times, the system in question has faulty RAM. This wouldn't help with that either.)