If folks have enough programming experience with other languages, it's easy to write Perl that looks more like those other languages, but unfortunately the moment a developer gets overworked or wants to show off (opposite extremes, really), Perl can devolve faster than some other languages because so many tricks are possible when vigilance is not maintained.
I've had decent success with making one-class-per-file with MooseX::Declare and Method::Signatures::Simple, but you really have to have a good code review process and rock solid developers to make it happen.
I don't think it's the languages fault, as this can happen just as quick in (say) Ruby code, and you can write extremely bad code in any language. Those other languages tend to be slightly faster to develop in though, as you can forget all of the need to write things like "my" and the reference syntax. Things like Python and Java have some resistance to "having fun with syntax games", but fall into other traps where interesting syntax (or architecture games) become fun or quick shortcuts.
On one end, part of Perl's problem is not Perl at all, just that it was historically the first thing people learned after Bash, and often those folks really didn't learn to program yet. On the other end, it is easy to go crazy with it.
Warning -- This article posts a longwinded first person account and finally ends with "this scenario is purely hypothetical". So it sounds like it is talking about a security vulnerability with git that really happened (signed commits or tags being broken, perhaps?), and it's actually an article saying you should use signed commits if you can't control access to your repo.
Key lines: "Somebody please look at the diff. Thats a simple 3 line code addition. I agree to you @torvalds but you could have excused this time :)"
AND: "By the way, its quite funny that github is sending instructions to @torvalds on using git."
Neither of which lines does Kenneth mention.
To me, this post is like the selective editing FOX News or the Colbert Report occasionally do to take things out of context.
Not a fan.
It's hard being a project maintainer. Linus was more than explanatory. This is the kernel, after all, dealing with github gen pop can be quite tiresome, and I don't blame him at all for not wanting people to be throwing rocks at him.
I think the point is, and forgive the harshness of this, but the person to whom Linus called a moron was kind of being a moron.
Linus explained why he wouldn't accept pull requests from Github, due purely to the formatting of the commit log, and that guy starts insisting he do it because it's only a three line patch, basically ignoring everything that Linus had said.
Regardless the length of the patch, it doesn't alter the commit formatting.
I personally don't think I'd have ever resorted to calling someone a moron unless I personally knew them, but I very distinctly believed that guy to either missing the point, or trolling.
I believe you used to be able to click on the "forks" and "watchers" button to see who is forked or watching. Now the button defaults to "unwatch" when looking at the project page.
I find these new icons confusing as well. It took me a long time to figure out the one icon was an eye with a "X" on it for "unwatch". Not sure why the branches in "your fork" travel upwards as well, as I've never seen a source control diagram do that.
And my default user/organization/project icon is no longer an octocat but a book with a fork on it. I miss the octocat.
I think this is a classic problem when a graphic designer doesn't have enough meaningful real work to do :)
Thanks for that! We gave up on chef when one of their version updates failed to work with a prior version, both of which were the OS package defaults. Chef silently failed, no error message, nothing in the docs, nothing even in the source code. Had to do a fair bit of searching to find out why.
When open source projects like chef have nobody interested in even documenting much less testing backwards incompatibilities we move them to the bottom of our to-eval list.
This also illustrates a problem in article's blind enthusiasm for the latest revisions and libraries i.e., it dismisses the headaches this causes end-users, who often don't have staff or budget to fix whatever breaks during an upgrade. That said we are at least talking about python, which has had better release QA and backwards compatibility than perl, ruby or, gasp, php.
That said we are at least talking about python, which has had better release QA and backwards compatibility than perl....
I'm curious as to your experience here. I've found that Perl has by far the best backwards compatibility and release QA of the major dynamic languages. What did you encounter?
We don't use as much perl as we used to but the last upgrade issue was amavisd-new (a Spamassassin wrapper). Spamassassin has perl version issues every so often as well. NetDNS used to introduce new bugs about every 4th revision but seems to have been stable for the past couple of years. GNUmp3d and many audio libraries have non-perl revision-related, backwards-compatibility issues with some regularity.
Cool, I'm also investigating the python-based salt stack: http://saltstack.org/ for this purpose but it seems a bit heavy just starting out. Gonna try ansible next.
Yep, this is a pretty lame ranking system. Projects are given more points the more people are registered in them with accounts on the system.
Compare this with what Ohloh does, where someone can be ranked in the top #10 of contributors (or projects) without even signing up.
Ohloh doesn't offer very interesting stats, so I was expecting something more for stats junkies, but this is considerably worse in most all respects.
It will result in Flickr-like interestingness numbers, where people who play in the social network have more ratings, rather than a system that identifies the most important projects or the most widely active developers.
We don't feel confortable ranking projects and people based on info from not registered people, just our choice.
One of the things that really differentiates our ranking from Ohloh's is the way we calculate the DevScore. The DevScore it's not a popularity rank and it's not based on the amount of lines. The DevScore tries to measure the impact of your contributions (measure the amount of code, the reputation of the project and the reputation of the people that you work with) and of course we are continuously improving it and open to heard feedback.
If folks are wanting to check this out, my work build some VMware appliances for it. You should be able to get the server running in just a few minutes. Anyway, in case it's useful:
