I am generally a big fan of Julien’s work and I’m very excited for the future of OpenStack Ceilometer of which he is the current PTL. However, in this case I think his views are understandably biased towards review workflows on very large projects like OpenStack, and I found the length of the rant slightly disproportionate to the actual substance of the points made within it. Somewhat ironically, AFAICS his blog’s own review process could use some improvement due to comments currently being disabled So here are my thoughts.

Disclaimer: currently I use GitHub for reviews more regularly than Gerrit, so my views are likely to be biased at least as much as Julien’s, but in the opposite direction

Barrier to entry too low?

Julien says:

The pull-request system looks like an incredible easy way to contribute to any project hosted on Github. You’re a click away to send your contribution to any software. But the problem is that any worthy contribution isn’t an effort of a single click.

Doing any proper and useful contribution to a software is never done right the first time.

That’s an unhelpful over-generalization. There are plenty of cases where the low barrier to entry of a single click means the difference between a worthy contribution being merged and it never being sent. Fixing typos is the classic example, but there are others – small tweaks to comments and docs, one-line bug fixes etc. I work on several small projects for which setting up Gerrit would be complete overkill, and GitHub’s PR mechanism is a godsend in this regard.

So I’d suggest that one size does not fit all, and the larger the project, the higher the barrier to entry should be.

Preserving rewritten history

The problem is that if your contributor does this [history rewriting via git rebase --interactive] and then repush the branch composing your pull-request to Github, you will both lose the previous review done, each time. There’s no history on the different versions of the branch that has been pushed.

This is not quite correct. Julien is right to point out that GitHub doesn’t provide history of the commit SHA1s via the web UI or via the API. This is indeed a crucial flaw I have not seen any evidence that GitHub exposes anything akin to reflogs, and this flaw aligns with that, so it may be a deliberate design trade-off they decided in order to save on disk space (although that doesn’t sound like a big saving to me).

However, let’s give credit where it’s due: GitHub does provide history of the review discussion, and in particular has quite a nice feature for handling comments on outdated diff hunks. If someone submitted a pull request with (say) two diff hunks, you provided feedback on both, and then they force-pushed new history which only changes one of those hunks, then the pull request page will now only show one of the hunks as outdated, so both the contributor and the reviewer can see that one hunk needs a fresh review, and the other still contains unresolved issues. Here’s an example pull request I just made to illustrate it. GitHub presents a chronological history of the review:

• the first version of the patch is lamentably missing from near the top,
• the final version of the patch is near the bottom, and
• discussion over now-outdated diff hunks are initially collapsed for brevity.

You can click to expand the discussion over points which are outdated. For comparison, here’s the JSON returned by the API for the same view.

Gate testing

Gate testing is very easy to set up on GitHub projects using Travis CI, and integration between the two systems is very nice.

Again, I agree with Julien that the weakness of this approach is that (AFAIK) Travis only runs the tests against the tip of each pull request branch, rather than for each commit within it, and this leaves the project more vulnerable to pull requests which contain broken commits. I am every bit as passionate about history cleanliness as Julien, as you can see from my previous blog on the subject. However, this assertion is inaccurate:

With such a restriction, it’s impossible to have “fixup commits” merged in your project and pollute the history and the testability of the project. […] This implies that no broken patchset can ever sneak in, […]

Even if the tests pass for every commit, that does not prove that the pull request contains no fixup commits. For example, a fixup commit might fix a typo in a comment introduced by a previous commit in the same series. The typo won’t break any tests, but it will pollute the history. So testing every commit is very good (if you can afford it), but it’s not a panacea.

Other opinions

I am an occasional contributor to git itself, and I find it interesting to note that those folks are absolutely religious about reviewing patches via the mailing list, using git format-patch and git send-email, rather than via an external tool such as GitHub or Gerrit. Although the maintainer does an incredibly good job, there are occasions where patches can get accidentally dropped or the wrong version taken, and my personal preference would be to use a more structured system like Gerrit to defend against this. However every system has its strengths and weaknesses, and I’m fairly sure they have good reasons for deliberately choosing not to use Gerrit.

Additionally, Linus absolutely hates GitHub pull requests

Conclusion

Yes, GitHub has some crucial deficiencies in its pull request review workflow. But nevertheless, for small to medium-size projects, what it offers for free can be incredibly useful, and I for one am very grateful.

In the future I hope to use Gerrit more often than GitHub, but I thought it was worth partially defending the underdog here

The post in partial defense of GitHub’s review system appeared first on Structured Procrastination.

As George Santayana famously said, “those who cannot remember the past are condemned to repeat it”. In light of recent news regarding music notation software, I would add with some disappointment and frustration that those who choose to ignore the past are also condemned to repeat it.

For those of you who don’t already know, Sibelius is a proprietary software product for music notation which has for many years been one of the most popular choices for professional musicians and composers. For many of the more experienced customers in the technology industry who have already been burned in the past, a heavy reliance on a single technology is enough to trigger alarm bells – what if the company providing that technology goes bust, or decides to change direction and cease work on it, or simply does an awful job (*cough* Microsoft *cough*) of maintaining and supporting that technology? Then you’re up a certain creek without the proverbial paddle.

In the IT industry, this is a well-known phenomenon called vendor lock-in. A powerful movement based on Free Software was born in the early eighties to free computer users from this lock-in, and is now used on billions of devices world-wide. You may have never heard of Free Software, but if you own an Android phone or a “broadband” router, or have ever used the Firefox browser or Google Chrome, you have already used it. The vast majority of the largest companies in the world all run Free Software in their datacentres around the world; for example, every time you access Google or Facebook you are (indirectly) using Free Software.

What does any of this have to do with Sibelius? Well, in 2006, Sibelius Software was bought by Avid Technology, Inc., and despite remaining a very successful business, in July 2012 Avid laid off the entire Sibelius development team, effectively condemning the product to rapid decline and a very uncertain future. This decision received widespread condemnation, and yet Avid have refused to waver from their course, potentially stranding millions of users in the medium to long term.

I do not wish to criticise those users for locking themselves into a proprietary solution in the first place. Many of them will have been encouraged along that route during their education (many music colleges provide Sibelius to students, for example), and will have never heard of Free Software, let alone realised that viable alternatives do exist. These people are specialists in music, not in technology, so it’s entirely understandable that they just want music software which works well, allowing them to focus on making music rather than learning technology. (In contrast, I have no sympathy for anyone working in the IT industry who subjects themself to proprietary lock-in; full-time technologists really should know better… but I digress.)

However, what does really frustrate and disappoint me is the news that the sacked team of Sibelius developers have announced that they are repeating history by starting work on a new proprietary product at Steinberg which has the same fatal flaw. In that blog post, Daniel Spreadbury writes:

Of course there are dangers inherent in starting again from scratch, but since we don’t have any code of our own to use, we have no choice in any case.

As a long-term professional musician and professional software developer who has recent experience of enhancing music notation software, I simply cannot understand this statement, since both MuseScore and GNU LilyPond would serve as excellent starting points for a world-class music notation product. Daniel is well aware of the existence of LilyPond, as shown by one of his responses to a reader who commented on his blog:

Lilypond is wonderful software, and it’s great that its proponents advocate for it so strongly. I hope we will demonstrate to you that our experience and, yes, our taste in musical typography makes our new application a worthy rival, even if it is (to you) a useless, closed source white elephant.

I am sure that he and his whole development team are equally aware of the existence of MuseScore. Therefore despite a clear, publically stated awareness of the risks, they are deliberately choosing to start from scratch, rather than enhance existing pieces of Free Software in a way which would benefit everyone (more on that in a bit).

I can only hazard a guess as to why Steinberg have decided to go this route, but let me first bust some very common myths about Free Software which are relevant here:

Myth #1 – you can’t run a business or make a living off Free Software.
This one’s incredibly easy to address, because I can and do! – quite comfortably, thank you very much. I work (part-time) for a highly successful global software vendor which has sold services related to Free Software for over 20 years. We are (still) profitable, and growing fast, as is the number of other companies following suit. How is that possible? By selling services, not licenses. In other words, selling good old-fashioned honest expertise. That can come in many forms: software maintenance (i.e. bug fixes), upgrades, technical support, documentation, consulting, training…

Secondly, it’s “Free” as in free speech, not as in free beer. The founder of the Free Software movement specifically encourages the sale of Free Software.

Myth #2 – it only runs on certain systems which most people don’t use.
Both LilyPond and MuseScore already run on Windows, MacOS X, and Linux.

Myth #3 – it’s written by a bunch of hobbyists / it’s lower quality / you get what you pay for etc.
These statements are no more useful than any other sweeping generalisation. Are Firefox and Chrome better than Internet Explorer? The vast majority of IT professionals would say yes. But there are also plenty of counter-examples. So let’s focus specifically on music notation software.

I suspect that Daniel and his team would gracefully agree that LilyPond produces extremely high quality output, in many cases (admittedly not all) even slightly superior to the output from Sibelius. This is no surprise, because output quality is LilyPond’s primary concern. They would also quite rightly point out that LilyPond is challenging to learn for less technically-minded people who tend to want to be able to do most work with the mouse. MuseScore has an interface somewhat similar to Sibelius and goes a long way towards addressing this group of users, but its output is currently nowhere near the same quality.  There are also promising front-ends for LilyPond, such as Denemo.

Since these are Free Software, any developer is free to take the existing code and enhance it in any direction they want. So the Steinberg team could have for example used LilyPond’s superb rendering engine as a starting point, optimise it for WYSIWYG rendering, and build a superb Sibelius-like graphical user interface (GUI) around it. Or they could have started with MuseScore and work on enhancing both the rendering engine and the GUI.

You may ask, but why should they? What are the benefits of Free Software? Here’s one rather amusing answer, and a slightly more helpful one. I’ll add two more specific examples in this context. Firstly put yourself in the shoes of a poor music student, or a musician trying to make a living in a very poor country. Without access to good Free Software, the only choices are: obtain an illegal copy of a commercial product, or go without. Now imagine you are a high-earning film/TV composer, and whilst working on a contract you discover a bug in the proprietary software which makes your life very difficult. You report the bug to the company who develops and sells the software, and they politely decline to fix it (or more likely, ignore your request). The only choices here are: live with it, or switch your whole studio setup to another product.

So it’s clear how Free Software makes the world a better place. So why then have Steinberg decided to start from scratch, despite the extra risk and man-years of work this will cost? Only Daniel and his colleagues can answer that, but my guess is one or more of the following:

• They just don’t “get” how well Free Software projects can thrive and offer opportunities for making money.
• They do “get” it but they believe that the profit margins in Free Software are too low for their business strategy which involves making truck-loads of money e.g. through being the sole distributor.
• There’s a perceived technical barrier. For example, maybe they really really don’t want to use C++. (I can sympathise with this sort of stance, but it’s still not justification for working on a proprietary product.) Or maybe they have a fundamental concern with the existing architecture of LilyPond or MuseScore. For example, in a response to another comment on Daniel’s blog post, he writes:
  

  The difficulty with complex applications like scoring programs is that a great deal of the richness of the end result that you see visually on the screen or on paper is worked out algorithmically from the small amount of data actually contained in the file saved on disk. Even if you consider Lilypond, the Lilypond file format itself does not describe exactly how the finished score will appear, because it is up to Lilypond itself to handle positioning, spacing, etc. based on its own internal algorithms and rules.

  but that misses the point that it is entirely possible to get LilyPond to output positioning/spacing information which could then be fixed across LilyPond versions and embedded within a non-brittle output file format. In fact, with a few hours of help from Jan Nieuwenhuizen, one of the co-authors of LilyPond, I implemented that recently myself for the ly2video project without even having to modify LilyPond’s core C++ code.

It further saddens me that this announcement is being considered as a reason for celebration, when as far as I can see a different path could so easily have been chosen which would benefit everyone more. However I suspect these sorts of opinions are simply due to an honest ignorance of Free Software. I hope that in a very small way this post might help address that.

The post music industry learns nothing from the Avid / Sibelius saga? appeared first on Structured Procrastination.

• http://cellobello.com/blog/chamber_music/cello-is-my-co-pilot/
• http://cellofun.yuku.com/topic/4483

My situation is different because I have a Luis and Clark carbon fiber cello which is incredibly robust and generally does not even go out of tune when checked in as normal baggage and placed in the hold of the aircraft in a normal hard case. My case is a Bam Hightech measuring 54.5 × 21 × 13.75″.  It seems virtually all airlines policies regarding oversized baggage operate in “linear” or total dimensions, which generally means by summing up the 3 separate dimensions together (although in some cases the wording is so confused, even that’s not clear).  This means my case has a linear dimension of 89.25″ which unfortunately is outside the 62″ standard limit, and even just outside Delta’s second tier limit of 80″.  Having said that, so far I have always managed to get it treated as normal sized baggage just by behaving exactly as if it was a normal suitcase, or even need be simply by confidently pointing out that the height is 54.5″ which is under 62″. In my experience, most staff at the check-in gate are not familiar with the exact terms in their airline’s policies, so having the right attitude (confidently knowledgeable and up-front but non-confrontational) can go a long way.

I’ve done some research on the policies of some popular airlines and referenced the relevant extracts below, with one section per airline. The quotes I’ve taken are focused mainly on national flights within the USA, because despite being from the UK, I’m currently flying around the USA a lot. However the policies for international flights seem similar, although sometimes with higher fees.

N.B. In addition to the below fees, most airlines typically charge around $25 for checking an extra bag.

Delta Air Lines

http://www.delta.com/traveling_checkin/baggage/special_baggage/musical_instruments/index.jsp

What Musical Instruments Can Be Checked?
Musical instruments or equipment can be checked if the total linear dimension (length+width+height) does not exceed 115 inches (292 cm) and provided the weight, including the case, does not exceed 100 lbs. (45 kg).
Standard rules and fees for overweight and oversized baggage

http://www.delta.com/traveling_checkin/baggage/excess_baggage/index.jsp#oversize

175 USD/CAD* for bags measuring 63–80 inches (161-203 cm) in combined length, width, and height. Some Specialty Items may be exempt from this fee.

300 USD/CAD* for bags measuring 81-115 inches (204-292 cm) in combined length, width, and height. Some Specialty Items may be exempt from this fee

Summary – could cost over $300 but been lucky so far.

Jetblue Airways

http://help.jetblue.com/SRVS/CGI-BIN/webisapi.dll/,/?St=351,E=0000000000047971896,K=4928,Sxi=18,Case=obj(2132)

Musical instruments as checked baggage:
There is no charge for Musical instruments as long as they are within size and weight requirements. JetBlue accepts no liability for damage to Musical instruments. We suggest packing them in a hard-sided container designed for travel.

http://help.jetblue.com/SRVS/CGI-BIN/webisapi.dll/,/?St=351,E=0000000000047971896,K=4928,Sxi=18,Case=obj(634)

63 – 80 inches (203.2 centimeters): $75 per bag
Bags over 80 inches: Will not be accepted

Summary: could be forced to buy an extra cabin ticket, or even turned away. However they have a good reputation amongst cellists.

United Airlines

http://www.united.com/page/article/0,6867,50773,00.html#music

However standard oversized baggage allowed up to 115 linear inches:

http://www.united.com/page/article/0,6867,52907,00.html#oversize

for fee of $100:

http://www.united.com/page/article/1,,53403,00.html

Summary: musical instruments discriminated against and limited to max of 62″ whereas other oversized baggage can go up to 115″ for cost of $100.

Frontier Airlines

http://www.frontierairlines.com/frontier/plan-book/travel-info-services/baggage/baggage-chart.do;jsessionid=5DBD43BCE9C1368C59705E648F626AD4

For musical instruments, no extra charges but excess, oversize and overweight charges apply if applicable.

http://www.frontierairlines.com/frontier/plan-book/travel-info-services/baggage/checked-baggage.do

We know it’s a weighty issue, but please remember items which exceed 62 linear inches (length + width + depth) or weigh more than 50 pounds will incur a fee. There is a $75 fee for bags exceeding these weight limitations and a $75 fee for exceeding the size limitation. These fees are charged separately and one item can incur multiple fees. You can read more about baggage in the Contract of Carriage (PDF).
We take the safety of our passengers and employees very seriously. Frankly folks, our employees have to lift and carry these bags to get them to your flight and we’d really like to keep those checked bags under 50 pounds each. And, as much as we’d like to help, we don’t accept baggage that weighs more than 100 pounds or exceeds 110 linear inches (length + width + depth). If you need to transport items this large, please check with your favorite package delivery company. Thanks for your understanding of our policy.

Summary: $75 worst case – the best policy I’ve found so far.

Continental Airlines

http://www.continental.com/CMS/en-US/travel/Pages/BaggageExcess.aspx

Oversized Baggage

• Customers who travel with checked baggage exceeding 62 linear inches (157 cm) (total length + width + height) will be charged at the rate of $100.00 per piece for travel within the U.S., and between the U.S. and Canada, Puerto Rico, and the U.S. Virgin Islands. Customers to Mexico, the Caribbean, Central America, and South America with oversize baggage will be charged at the rate of $200.00 per piece.
• These charges are in addition to any charge assessed for additional or overweight baggage.
• Baggage measuring more than 115 in (292 cm) (total outside dimensions; length + width + height) will not be accepted as checked baggage.

Summary: $100 worst case.

American Airlines

http://www.aa.com/i18n/travelInformation/baggage/baggageAllowance.jsp#overweight

Checked baggage which is larger than 62 in/157 cm will be charged at the rate of $200 per piece.
Baggage measuring more than 126 in/320 cm will not be accepted as checked baggage.
…
Instruments may also be transported as checked baggage, however, due to their fragile nature AA does not accept liability for damages and has limited liability for loss. AA is also not liable for any damage to checked musical instruments not presented in a hard-sided case. If the outside of the hard-sided case does not have visible damage, AA is not liable for any damage to the musical instrument inside the case.

The implications of the last two sentences don’t make any sense – if they do not accept liability for damage (as in the previous sentence), why even bother specifying requirements for hard cases and visible damage on the outside?

Summary: as bad as Delta, and with highly ambiguous wording regarding liability for damage.

Conclusion

Any cello case, even a non-flight case, will exceed the standard 62″ limit for oversized checked baggage, and unless you are lucky at check-in, will incur a fee typically around $75 to $100. Most cello cases are unlikely to top the overweight baggage restrictions. Generally musical instruments are subject to a slightly different “special baggage” policy to normal checked baggage, but usually this amounts to a disclaimer of liability and similar or identical rules regarding dimensions.  Some airline policies are much worse, e.g. Delta, will potentially charge a whopping $300 for exceeding 80 linear inches, but having said that I have travelled with Delta several times and they didn’t charge me any oversize fee at all, just the extra checked item fee. United could potentially require a cabin ticket, and Frontier have the cheapest and most tolerant policy I’ve found so far.

The post Flying with a (carbon fibre) cello appeared first on Structured Procrastination.