Re: [SCM] tomcat6 packaging branch, master, updated. debian/6.0.35-6-1-g3c65d46
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.
> 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.
>
> 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.
>
> Cheers,
> tony
>
> [1] http://pkg-java.alioth.debian.org/
> [2] https://wiki.debian.org/Teams/JavaPackaging
>
Cheers,
--
Stephen Nelson
Reply to: