The cabal may be german, but clowns are definitely french^[1].
                  a SRM-assistant that asks for anonymity

summary of the problem

I've re-read most of the calm and useful posts (yes some exist if you look hard :D) in the java-tro^H^Hhread.

Yes, the pro-java-in-non-free are right — if we omit to mention all the difficulties it will imply if such a removal has to happen for a stable update^[1] — removing java from our mirrors do terminate the license solve most of the issues. Though, two major concerns remains:

1. clause 2.f (you agree to defend and indemnify Sun and its licensors from and against any damages ... and so forth) is IMHO unacceptable, even for non-free, because debian isn't in a position where it can risk to see that clause exercised by Sun ;
2. section 4 (and others of the same sort) makes the existence of java in non-free depending of Sun's mood: exercising clause 4 is trivial — they just have to imagine a new kernel feature our kernel should support that we can't provide to terminate the license retro-actively. Many instances of that problem exists in the license.

The first problem in itself seems obvious, and none of the arguments of the pro-java-in-non-free have put me at rest.

The second problem is a real concern because it means that our java support can be discontinued without possible clean upgrade path back to java-package. If Sun could not retire our right to redistribute one given version of java, then we could repackage the last version we can distribute with some debconf dialog to warn the user his java package won't be upgraded again, and that he must fall back to make-jpkg. But here, if Sun decides it, Sun can make the package simply disappear. And given the number of users that will concern, this is not a problem to be taken lightly.

I honnestly believe that putting java into non-free, whereas we already have java-package that allow a quite satisfying integration of Sun's JDK/JRE into a debian instance, implicitely means that we are confident that java will stay in here forever (or for a significant enough time). And I see nothing that can guarantee such a fact, and I see too many things that can prevent this with a probability significantely greater than 0.

Yes there I know there is a FAQ about those issues, where Sun promise they won't use their power to hurt people. But if they don't itend to, why did they put those clauses in the license ? With all the good will I can provide, that does not makes sense to me. If you put landmines in your garden, well, that's for a purpose, not for the garnishment.

debian issues

And then, I've a couple of questions there, for which I've seen no real answer:

• why did that announce has been hurried like that ? yes Sun hadn't published their license, but I still don't understand how it can explain such a hurry.
• will debian switch to python 2.5 directly, so that we can skip one transition ? (that could explain why some maintainer have more time to dedicate to non urgent non-free packages, whereas some other would need its plain attention for etch)
• a more polite version of the previous question is: why do some people have been working soooo fast on this, when those people have other very real problems to deal with for etch ? that looks like a childish schedule, that puts shiny-public-things first^[2] instead of the problems that block a lot of DDs in their allday's work (some complains about NEW beeing stuck — and it is, and was even before Debconf —, other complain about the python2.4 transition that lags since ages, and other examples exists …)
• why did only 3 persons worked on that, for a package that :
  • is well known ;
  • will obviously make noise, given to its history wrt the free software world ;
  • has a license that seem to have some obvious problems ;
  • …

and I'll skip the questions I don't want to ask, or more precisely I don't want/fear to read the answer to:

• why does this come 1 week after that ubuntu made it clear they had some things going on with Sun ?

Disclaimer

Don't get me wrong. I've been really happy when I've seen that java entered non-free (even if I don't like the language — but that's another story and is off topic here), because that meant that progress had been done in the good direction, and that's a thing I just have to praise.

But then I've heard people complain about the damn license, and went read it. And then, I've been really disappointed, and I felt betrayed by those three people:
yes, I'm a DD, but I'm also a Debian User, and I trust my fellow developpers to bring to debian packages that don't have license issues, and will be supported enough^[3]. As a user, I feel betrayed because nothing that I expect from a package that is in debian (even in non-free) can be guaranteed for the java package.

I received a mail :

Subject: New Debian maintainer Pierre Habouzit

Dear Pierre Habouzit!

Your account 'madcoder' has just been created in the central ldap database of the Debian project. Please note that it needs a bit of time until this information is synced with all developer-accessible machines, you should be able to login or upload packages after about 30-60 minutes. […]

wow, 1 year already…

Yeah, we did the past 10 days an extraordinary amazing job of triaging. almost 200 bugs that rot here since ages are now closed (hopefuly for good). Still a bit less than 1200 (non forwarded, non wontfix, non pending) bugs to triage, but still, it's a big step !

bts-link was of great help, to track bugs that were closed upstream since ages, and that we missed.

Before, I rarely took the time to forward bugs upstream, because I though: « what the heck, I won't have the courrage/time to follow its evolution upstream, and it will rot in the 1000 other bugs ». bts-link put an end to that time.

Trac support

Thanks to the preliminary work from Sanghyeon Seo (aka sanxiyn) bts-link has now a Trac support^[1]. Sadly, there is no way in Trac to follow Duplicates like I do for bugzilla. I think I'll try to develop some heuristics to guess it, but it's for later.

A lot of improvements have been made since my post on d-d-a@:

• the changes are now incremental (meaning, you can retire a fixed-upstream tag if you feel it's not true, bts-link won't put it again) ;
• the changes are grouped per source package, and sent to $(source_package)@packages.debian.org so that maintainers don't miss it, even if there is only usertags changes ;
• the mail is now commented so that maintainer don't have to figure out what's going on in the commands, bts-link tells what it saw, and takes the necessary steps.

I want to polish some bits of the code, but that should be done soon, and contributions to create new backends will be welcome.

Also note that any mail bts-link send, or receive from debbugs is archived on the bts-link-upstream list on alioth.

What's next ?

• I want to make bts-link more simple to use, so that set up a bts-link service does not need too many manual steps
• I want to provide some tools for the Maintainers so that they can run partial pulls for their packages, or as a tool to “forward and pull” their bugs, instead of using bts(1)
• I want to support some very widespread BTS, especially sourceforge/gforge/tuxfamily ones, the infamous IssueZilla^[2], as well as mantis (other backend will be welcomed of course, but those 3 are the most used atm).

Edit :

Bts-link has now Savane (Savannah bug trackers) and IssuZilla (openoffice and a couple of projects) support.

Bts-link now supports sourceforge trackers.