Hi, I suggest to drop the security team and Moritz from further replies because we are starting to change the discussion topic. I recommend to discuss changes to Debian's security policy on debian-devel or with the security team directly.
Am 11.12.2017 um 23:24 schrieb Emmanuel Bourg: > Le 11/12/2017 à 19:49, Markus Koschany a écrit : > >> You can refuse to >> work on it but please do not block other people from doing the right >> thing which is either to fix bugs or remove bit-rotting and broken >> software from Debian. > > Huh?? I'm certainly not blocking anyone from fixing jasperreports or > libpam4j. I'm just putting the issues into perspective and trying to > convince you that there are more important things to do with our limited > resources. I failed, well, so be it. But please don't see that as > negative, I hold absolutely no grudge against your position, I'm > sincerely grateful that you invest so much time into the Debian Java > ecosystem and the security support. I'm just someone pragmatic that > likes doing things that make sense, and I feel concerned when someone is > about to spend a significant amount of time on something unnecessary > (not by the rules, but by the impact it'll have on actual users). Thanks for your concerns. You don't need to worry though because I know how much time I should sensibly spend. It was neither time consuming nor difficult to fix libpam4j in all distributions. The question is what kind of message do we want to send out? I want a usable and secure system by default and all resources for this goal are a good investment. If libpam4j had been a package in testing, it would have been removed from said distribution because of the grave bug. Just because someone discovered the bug after we released the package, doesn't mean we should ignore it. This makes me wonder whether I should touch any package with a popcon value lower than 100, or 1000, or 10000 installations from now on. Who decides what is important. According to your logic we probably only need to support Tomcat and all its dependencies which can also be ignored if they only serve as build-dependencies. I want to be able to recommend Debian as a Java platform. With Fedora we are the only ones who actually put some effort into integrating Java into a Linux distribution. The rest is either downloading dependencies from the internet without further checks or they just distribute binary files without source. Of course we could do the same which would save us a lot of time. What I mean by "blocking" is, you have the tendency to veto or protesting against too many, in my opinion, completely valid decisions. Azureus has been broken for a very long time. There was a lot of time to react to all open RC bugs but nothing happened. Finally the day arrived when we wanted to remove the package and you delayed the removal again. Actually I feel bad about it because I think I'm a bit too pushy but on the other hand it doesn't make sense to keep a useless package in Debian and there was really enough time. The result: Azureus is still not removed from Debian, nor has it been fixed. Now I have reached the point of: I don't care anymore. >> If we can't even support the status quo then introducing new features >> and packages will only increase the burden. The reason why we struggle >> with big changes like Maven2->Maven3, Java8->Java9 is foremost the lack >> of manpower, lack of communication and lack of a strategy to minimize >> the brokenness in unstable. It has simply become too hard for >> contributors to keep up with the changes. When only a select few know >> why something is suddenly broken, chances are very slim that someone >> else will fix it. > > Do you mean that I'm holding important information and that's why we > don't see more contributors joining the party? I don't think this is a > fair assessment. Look at the Java 9 transition, Chris posted the bug > list months ago and no new contributor showed since, we are just a > handful of regular contributors slowly fixing the bugs. For the Maven 3 > transition I requested some help with plexus-utils2 last month and I got > absolutely nothing. No, I don't blame you for the lack of contributors. My point of criticism is that you managed the Maven 3 transition single-handedly without a plan how other people could contribute to it. I remember that I asked this question on the list and your reply about plexus-utils2. However I just couldn't wrap my mind around this topic because I didn't understand your reasons why you updated package x first, that broke 5 packages, then you updated (seemingly) unrelated package y, which broke another 5 packages, then you introduced foo-bar2 and switched 10 build-dependencies. Then you packaged a new release of xxx that broke two more r-deps but that wasn't even related to Maven 3. And here I lost it because I had to spent a lot of time to figure out what actually caused this FTBFS. Was it because of the transition or something else? This is probably completely clear to you but if you are not working on those updates it is quite hard to grasp for outsiders. That's why I would prefer that you start one project like Maven 3 and complete it without getting distracted and organize such a complex update in a way that other people might be able to help you. The idea is that people understand all the steps and can digest all the pieces. Take the recent Gradle update for example. I updated the package, rebuild the majority or most important r-deps, discovered that two packages FTBFS now and asked for help. You replied with a very helpful comment and we could immediately fix one of them. Now it would be great if we completed this update together by patching, not upgrading, bnd because that would open another can of worms. One issue down. That's what I call a digestible piece. I know it is more difficult for Maven core libraries but the basic idea is to reduce the complexity when attempting upgrades. >> A build-dependency is still a supported package by default and binary >> packages of libspring-java are also used as runtime dependencies. That >> also doesn't change the fact that it is mainly a web framework and no it >> is not silly to use software as such if it is provided in Debian. > > I respectfully disagree. Depending on a Java library provided by the > operating system for someone doing cross-platform Java development is a > bad idea for many reasons : [...] Ok, I snip the rest because I have reached my mail limit for today. I wasn't talking about the developer, I was talking about the use in production. You know that Debian's libraries don't change for the next five years. So you ask your developer to test and develop the application against Debian's system libraries (we don't care about Windows or MacOS) because you don't want to take care of security updates. That is certainly only one use case but my basic thought is that you can't simply tell users how to use the software. That surely wouldn't work for other languages and I don't see a reason why Java should be any different. Regards, Markus
signature.asc
Description: OpenPGP digital signature
