Hi tony, On 28.08.2014 00:24, tony mancill wrote: [...] First of all thank you for this very informative post. [...] > Sustainability/Maintainability: > > I made a strawman statement about whether we might consider paring down > Java within Debian to just a JDK and a few core packages (e.g. tomcat > and related). This was intended to encourage discussion and to consider > what that would mean. There is no serious proposal to change the > current course of action, and despite phrases like "dependency hell," > the Java Team is a fun and rewarding place to contribute. We could use > more resources, and we welcome new members! I think the main reason why I enjoy fixing bugs in this team is because there is always someone who reviews and sponsors all those packages. And most of the credit goes to you and your outstanding and continued support. So I'd definitively like to underline the phrase "rewarding place to contribute". [...] > Old/crufty packages: > > Based on an email exchange with Emmanuel, I shared with the group that > despite me putting it on the agenda, the Java Team does not propose to > pro-actively remove packages currently in the archive unless they are > unpopular leaf packages that become problematic (e.g. RC-buggy). Admittedly my number one priority is currently the Debian Games Team and related topics. That's probably the reason why I pick problematic aka RC-buggy Java packages first when I try to make a contribution because here I can be sure that help is urgently needed. I strongly believe that working pro-actively on packages is the right way to go but I'm struggling sometimes with finding the right packages to work on. For example it isn't always obvious if updates are really needed because new upstream releases are very frequent and mostly small. On the other hand doing major updates especially for prime packages with dozens of r-deps introduces the big risk of breaking them. I think it would be more helpful if we defined priorities among those candidates and simply pointed occasional contributors to a wiki page where they can choose from various options sorted by priority. My reasoning for this kind of paper work is that people would be directed in the right direction and they could be assured that they would not step on someone's toes and work on the most urgent issues before they become RC. A drawback is certainly the additional work in maintaining such a "priority list" but I personally like the idea of internal (release) goals because they might help to focus on relevant problems. Cheers, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature