 |
|

 |
|
 |
 |
 |
 |
|
 |
 |
https://lists.launchpad.net/launchpad-users/msg05078.htmlNow I can't fault the reasoning for the delay. They want to make use of the new bzr backend as it has significant speedups. I certaintly can't say a speed up to bzr wouldn't be beneficial. If Canonical wants to say publicly that bzr isn't up to the task managing Launchpad releases..who am I to disagree with that assessment. But I find it a bit ironic, that development in the underlying dvcs that Canonical is funding the development of is holding up the release of the code hosting web services codebase that Canonical is funding the development of. Oh sweet irony. Here's how I would have written the same message: "I'm sorry, we'd love to release this code to you on the date we promised, but you see, we just aren't that thrilled with usability of the dvcs we've chosen to use internally and have been using internally for years and years now. We took a show of hands and yep, we all pretty much agree that the implementation we've been using for years blows monkey chunks and we don't want to inflict that experience on any external contributors. We've only been using it because we are paid to use it..we've had no choice in the matter. To be honest with you, we aren't even sure why anyone who wasn't forced to use it by their employer was using this implementation for any serious collaborative project. It's sooooo painful to use. So until the dvcs implementation gets better we're just not going to bother releasing the launchpad code. We think that this codebase is so very different compared to the thousands of other codebases already using the same dvcs that it just would not be worth trying. We think that its size and complexity of the launchpad code far surpasses the capabilities of the current dvcs implementation. Yes, the very same dvcs that we have repeatedly encouraged and forced thoursands of other codebases(like mysql and zope) to use to gain access the very same Launchpad infrastructure we are now withholding from the community. Don't fret however, as we've been working on upgrading the capabilities of the dcvs since last November, and the new capabilities should be reliable enough for us to make use of 'real-soon-now'(tm)...hopefully. Thank you, THE MANagement"
|
 |
 |
 |
 |
|
 |
 |








 |
|
 |
 |
 |
 |
|
 |
 |
If you are not familiar with the Fedora Client statistics effort take a moment and read: http://fedoraproject.org/wiki/Statistics I'd like to take a moment and talk specifically about how to do a better job at interpreting the total unique IP connections listed here: http://fedoraproject.org/wiki/Statistics#T otal_repository_connections There are two competing factors which influence how unique IP counts can be interpreted as client counts. On the one hand there is the effect of private subnets which map multiple clients to a single IP address. This would lead to the unique IP address count to be an undercount of the actual number of clients. On the other hand we know we have clients which roam across networks and those clients could easily be counted multiple times in the unique IP logs, leading to the unique IP counts being an over estimate of the actual number of clients. So which is it in reality? Is the 14 million+ unique IP counts sitting in the Fedora MirrorManager logs an over or under count of reality? I'm here to tell you friends, that its an undercount..by about 15%. There are probably about 16 million Fedora clients in the wild in reality. How do I get that? Easy, I had my buddy Mike "Chops" McGrath do a little data mining of the Smolt logs and come up with an aggregate ratio of Smolt UUIDs to unique IPs. That ratio can be taken as a scaling factor to convert unique IP counts to unique client counts given the following assumptions. 1) The smolt userbase represents a sampling of the overall client base which is no more likely to be on a private network than the average Fedora client. 2) The smolt userbase represents a sampling of the overall client base which is no more likely to have a dynamic IP address than the average Fedora client. 3) The ratio is reasonably stable over a release cycle timescale, but may be subject to a slowly varying drift. If those three assumptions hold the ratio of UUIDs to IPs is an adequate scaling factor. We looked over the last 16 months of aggregate Smolt logging data here is what we found: Mean Ratio: 1.16 Ratio Stdev: 0.0263 Here's is a graph of the Smolt ratios calculated monthly. I'm pretty confident in the validity of scaling factor. I'm also very pleased to see that the number is greater than 1. This means that the currently unique IP address statistics we are showing are a conservative estimate of the actual client numbers. No caveats, no soft-selling. There are 14 million+ Fedora clients out in the wild and its time we start making that point loudly and confidently. -jef"Measurement methodology matters"spaleta
|
 |
 |
 |
 |
|
 |
 |

 |
|
 |
 |
 |
 |
|
 |
 |
Okay, why exactly was steroid use by major league baseball players such a scandal? Objectively speaking, steroid use actually helped the for-profit businesses which keep major league baseball going make more money. Better hitting, better pitching...better ticket sales...better free agent salaries...better business. Steroids was good for the business which makes major league baseball possible... why wasn't it ultimately good for major league baseball?
I'll tell you why.. because baseball is more than just the business of selling sports entertainment, baseball like all professional sports competitions is grounded deeply on the sense of fair play. The ground rules of fair play are easy to summarize. Give competitors equitable and fair access to similar equipment and resources and let them compete against each other based primarily on personal dedication and skill under an established set of rules. Steroids upset the ground rules of fair play as it was perceived to be a quick fix to shore up shortcomings in either dedication and/or skill. Though I could probably argue it took a certain sort of personal dedication to the concept of achievement to inject yourself in the arse with a needle every day. I hate needles, I could never be a major league baseball player.
Steroids were great for the business of baseball..but it was bad for baseball itself. That's an important point...a point I think the open software ecosystem and the businesses which back it need to understand. I think proprietary web services maybe the equivalent of baseball's steroid scandal. Proprietary web services may in the short run be good for the business interests which support the open software ecosystem..but it might ultimately be very bad for the open software ecoysystem itself. Maybe not for exactly the same reasons, analogies are only good up to a point, but I think its worth reflecting on as an example of how business interests can work against the interests of the larger community.
I think the Franklin Street Statement on the freedoms of network services has come a little late as a a fully preventative measure, but it might not be too late to have a positive impact on aligning long term business interests with community interests to prevent a deep debilitating rift. Going back to the baseball analogy, its sort of like its 1988 when Tom Boswell broke the silence concerning Canseco's use of steroids in an interview with Charlie Rose on CBS. The Franklin Street Statement maybe that sort of moment. I'd like to hope the open development ecosystem will take less than the decade it took baseball to deal with steroids, to confront the business interests which are leveraging the concepts of proprietary web services which undermine the sense of fairness in the open development model.
-jef"play ball"spaleta
|
 |
 |
 |
 |
|
 |
 |



|
 |
|
 |