Am 12.08.2017 um 00:06 schrieb Emmanuel Bourg: > Thank you for the summary Tom. How many people attended the BOF? > > On 08/09/2017 02:50 AM, Tom Marble wrote: > >> 1. Making openjdk-9 the default for buster >> - Yes we should try to do this. >> - We will gain some fixes for reproducible builds > > Do we know what has improved on the reproducibility side with OpenJDK 9? I mentioned that you were the one who forwarded reproducibility patches upstream. So beside from that I'm not sure. > > >> - Chris West has done some excellent work trying to rebuild the >> archive with openjdk-9 >> - FYI: the next Ubuntu LTS in April would like to ship with openjdk-9 > > As the default JRE? That would be quite optimistic. If I recall correctly doku intends to switch the default JRE to Java 9 for Ubuntu 18.04 but OpenJDK 8 will still be available to build packages from source. This is like something we have done for Wheezy in the past. We support the runtime environment but if something has to be rebuilt from source an older version of the JDK has to be used. >> 4. Clojure >> - Currently does not have JDK 9 support >> - The Clojure Team will look into this with upstream > > Did you discuss if we keep the Java and Clojure teams/packages under the > same umbrella? We discussed this matter during the Clojure BoF. I said we would prefer (meaning we would be happy about it) that the Clojure team maintained their packages under the Java team umbrella. We already have all the infrastructure in place like mailing lists and Git repositories. However the Clojure team prefers to use a separate bug mailing list just to avoid all the high amount of traffic we receive every day. I suggested that both teams should grant access to each others repositories which would simplify collaboration and it appeared to me that everyone agreed to this proposal. >> 5. javadoc >> - Our packages that are standards 4.0.1 compliant should support >> "nodoc" > > maven-debian-helper will support the "nodoc" option in the next update, > but some help from debhelper is still required to make it work with no > other modification to the existing packages (see #871822). > > >> - Some users appreciate offline access to docs > > I would add that we spent a non negligible amount of time maintaining > these rarely used packages and dealing with their reproducibility > issues. Besides the JDK and some very popular libraries I think we > should drop them. I agree that most of the reproducibility issues are related to javadoc packages. However in my opinion this is something which should be fixed upstream. As you said we should provide documentation for the most popular Java packages and the JDK but simple Java packages don't really need it. I'm more in favor to apply this rule for future packages but I don't think we should drop -doc packages for older packages as long as they don't become a real burden. > 6. Autopkgtest >> - We should use this more >> - Can include built-in tests >> - We can (or autopkgtest already does) use 'ratt' to test reverse deps > > My understanding of autopkgtest was that it wasn't meant to execute the > test suite already run at build time (i.e. mvn test). Maybe it could be > used to run the Maven integration tests instead? I'm not sure about this. I believe it would be a good start to implement autopkgtest for our most important packages first. Something like checking whether r-deps break or not would be an improvement. On the other hand I am quite impressed by the current state of bug reports from the reproducibility team, so maybe we could focus on something else first. Markus
Attachment:
signature.asc
Description: OpenPGP digital signature