Callaway: Chromium: Why it isn't in Fedora yet as a proper package

Rather then taking your claims at face value, I thought I'd see for myself. Not that I don't trust your authority, with you being a packager and all that, but I have not seen you post once to fedora-devel-java in the past 15 months, so I assume that is not your area of expertise. In particular, I can't find your name in the conversation in the Fedora bugzilla entry for freemind.

The last attempt in the Fedora package database that I can find is

https://bugzilla.redhat.com/show_bug.cgi?id=428413

It's a packaging attempt by Alex Leamas. A quick check on the freemind site confirms that he is not one of the freemind developers. That's not a good sign - the freemind source code tarball is larger then a megabyte, so understanding it in order to make significant modifications likely requires a significant investment in time.

In addition, Alec says:

"This is my first attempt to provide a package for Fedora...

Also, it's a java application. There is an obvious need for guidelines for java apps, hav'nt found any."

Attempting to package a large application in a domain where the distribution has no obviously findable guidelines as one's first package - what could possibly go wrong with that?

Then, after some initial work, some license issues are discovered by spot, and he says:

"Yeah, you are going to need to get upstream to resolve these license issues."

Now this could be the moment where the upstream shows uncooperative, and the oh so horrible ways of Java developers are unmasked. Amusingly enough, that's not what the bug says - it says nothing at all about the packager communicating with the upstream and reporting back how that went. So one has to search for it and finds an upstream developer say:

http://www.mail-archive.com/freemind-developer@lists.sour...

"I change the licence of my file soon and have a look at the others."

I tried hard to figure out how one could possibly take that to mean "we're too unique". I don't see it - to me that sounds like a Java upstream bending over backwards to help with licensing changes to ease the packaging into Fedora. Quite a different picture in reality then being painted here by spot & rahulsundaraman, apparently.

But, as I said, no word about that in the bug report.

So, why does the packaging attempt, unsurprisingly, eventually fail?

"file bindings.jar is the result of a compilation of a xml file which defines the interface. It might be impossible to get this compilation, involving JAXP API:s to work.

When rebuilding jaxme and running the compiler I run into problems since the source xml file contains constructs not supported by the jaxme xsd compiler. It might be possible to walk around this, but I don't know enough about the JAXP interfaces to do this, at least not now."

Translation to English: Because the prospective Fedora packager doesn't know enough about the software he's trying to package.

But that's not the only reason, there is also

"Even worse, current CVS sources shows that freemind now uses Sun's JAXB suite to handle this. It does support all constructs, but it is at best GPLv2 only. And it does not build for me, some kind of config problem."

JAXB is, of course, part of the Java SE 6 platform, so it's in IcedTea, OpenJDK 6, etc. It's dual licensed under CDDL 1.0 & GPLv2 with the Classpath Exception. No one of Fedora's licensing experts catches that mistake, and asks the prospective first-time packager to try using IcedTea or OpenJDK instead.

So it all predictably ends with:

"My first attempt to submit a package has, for now, failed.

The main reason is that recent code (after 0.0.9Beta15) has became heavy
dependent on Sun's JAXB reference implementation (https://jaxb.dev.java.net). This code has it's own set of dependencies, and could not reasonable be a part of this package due to both technical and legal reasons."

So, the legal reasons come down to Fedora's experts not bothering to check the first-time packager's assumptions about licensing of an upstream dependency and fix his mistake.

The technical reasons come down to the lack of prospective packager's technical prowess with the upstream codebase, and its dependencies. On a meta-level, attracting contributors for the jobs they don't have a chance of doing well is a failure in Fedora's recruiting & mentoring process.

Through the whole effort, the upstream project does not claim that they're too unique, apparently. There is nothing in the bug report indicating that the bundled libraries were patched and the upstream refused to send their patches further upstream, either, even though rahulsundaraman claims that is the most common issue.

So for someone familiar with Java development, the sweeping statements about Java developers made by rahulsundaraman & spot looks more like playing on a bias for the purpose of blame shifting to the upstream for inadequacies in Fedora's processes, recruiting & mentoring in the area of packaging Java applications.

What has happened since?

"Could this be reopened? The latest Freemind release candidates (I've tried 0.9.0-RC3 and RC4) work just fine with the OpenJDK VM supplied with Fedora 10 (java-1.6.0-openjdk-1.6.0.0-15.b14.fc10.i386"

"Please file a new review request and mark this bug as
a duplicate of the new one. "

No duplicate marked so far.

There has been a freemind package in Debian since 2004.