On 08/04/2013 01:50 PM, Stephen Nelson wrote: > On Sun, Aug 4, 2013 at 12:57 AM, tony mancill <tmancill@debian.org> wrote: >> Yes, the procedure for a new tomcat release is to generate the new >> orig.tar.gz, import it using git-import-orig, and then determine which >> of the debian/patches can be dropped. Typically it's not that difficult >> to figure out because the patches are normally just those cherry-picked >> directly from the upstream SVN to address CVEs. Also note that 6.0.36 >> has already been imported, but I think we can skip that and go straight >> to 6.0.37. > > Hi Tony, > > Thanks for taking the time to reply and for clarifying the process for > new upstream releases. I see from the upstream change log that there > are quite a few changes in 6.0.36 and .37 so it could be worth getting > them into Debian. Agreed. I went ahead and uploaded 6.0.37 sometime over the weekend. Thank you again for providing the gentle push to get the ball rolling. Now that we have current versions of tomcat6 and tomcat7 in the archive, it's time to start planning to pull the plug on tomcat6. I'll follow-up on a separate thread about that transition. >> In the case of tomcat6, in case you're not already aware, the Debian >> Security Team has asked us to drop tomcat6 from Jessie since tomcat7 is >> available and the the additional effort required to manage DSAs over the >> lifetime of the release. That said, I feel like there is still a user >> community for tomcat6. At a minimum, we could keep the packaging >> current in the packaging repo on Alioth and possibly setup a PPA-like >> mechanism. Or, perhaps it would be permissible to block tomcat6 from >> migrating to testing but to keep tomcat6 in unstable (only). I just >> wanted you to be aware of that. > > I wasn't aware it was being dropped but I'm just getting started on > packaging so that's fine. I'm happy to get it updated and help to > maintain it. I'm interesting in helping with any of the Debian java > packages as I've been a user of Debian for quite a while so would like > to help the community if I can. Fantastic! The Java team can certainly use more contributors. >> First things first - if you're interested in helping to maintain >> tomcat6, that's great! If you're completely new to the process, please >> review the Java Packaging Project page [1] and the wiki [2]. >> >> I'm going to take this opportunity to propose what I hope is a >> light-weight process for coordination amongst team members. I believe >> I've set a poor precedent in the past by simply jumping in and uploading >> team-maintained packages for which I'm not listed as an uploader. This >> isn't a problem provided that the other uploaders aren't that active, >> but a few times it has resulted in duplicated effort. Therefore, I've >> been thinking that the general workflow should be something like: >> >> 1) Mail either the debian-java list or the current list of Uploaders >> indicating that you're ready and willing to work on a package. Allow up >> to a week for a response before continuing on to (2). >> >> 2) Add yourself to Uploaders and upload or post an RFS. >> >> 3) Stay in contact with other Uploaders and/or the list for subsequent >> updates. >> >> I'm thinking about adding these as general guidelines to the >> "Maintainer: Debian Java maintainers" line on [1]. Suggestions or >> concerns? > > I'm happy with that process to avoid any duplicated effort which is > particularly frustrating if people are giving their free time to do > something. I'll contact the existing uploaders before I begin any > changes on tomcat6. > > If there are other projects that need some simple work doing on them > I'm happy to help where I can. Is there a priority list of tasks > available? I'm a decent Java developer, pretty familiar with Debian > but only knowledgeable about packaging from a user perspective. I think you'll find that working with the Java team is as much "packaging" as it is "development," although there are development projects such as the maven helper packages if you're interested, and being able to patch/port to newer versions of libraries is always useful. There isn't a priority queue, but you'll often see requests for assistance with large packaging efforts posted to the list (e.g. most recently, related to netbeans [1]) and I think we'll have tasks related to the change from openjdk 6 -> 7 (at least for some architectures) and in transitioning the reverse depends on libtomcat6-java -> libtomcat7-java. And you can always take a gander at the list of bugs for the team maintained packages [2] and associated bugs [3]. If you're interested in something specific to look at, getting an updated azureus/vuze package would be helpful; otherwise we'll probably need to exclude it from jessie. Cheers, tony [1] https://lists.debian.org/debian-java/2013/08/msg00014.html [2] http://qa.debian.org/developer.php?login=pkg-java-maintainers@lists.alioth.debian.org [3] http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=pkg-java-maintainers%40lists.alioth.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-exc=done
Attachment:
signature.asc
Description: OpenPGP digital signature