-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Coty,
On 1/11/17 12:24 PM, Coty Sutherland wrote: > On Tue, Jan 10, 2017 at 3:14 PM, Christopher Schultz > <ch...@christopherschultz.net> wrote: >> +1 > > I'm glad someone is interested :) > >> Perhaps we could have some representatives from the various >> distributions give a joint presentation. > > That would be great. I'd love to meet the other distro > maintainers. [snip] >> I think it would be a good idea to use some of that time to >> solicit feedback from the audience about what the distros could >> do to make things easier... > > +1, definitely. I will to do anything that we can to drive adoption > of tomcat up (distro-specific versions or ASF). How about this: submit a topic to the Call for Papers[1] and choose "Panel Discussion" for the "Submission Type". If you can get some other maintainers coordinated, you can choose to prepare some slides (maybe 5 mins each) and/or come with some conversation questions to get things started with a panel. Open up to the audience as well. I suspect you'll get a good conversation going. I'll certainly be there unless I must be elsewhere. > The biggest concern that I've heard from various of the involved > people (and may be a reason why other distros don't consume > updates as frequently) is that tomcat is not that great at > maintaining backwards compatibility; Understood. > I hear this complaint a lot and I get push back from packages that > have dependencies on tomcat when I do push our new revision > updates. I know that some of the APR and httpd folks are absolutely rabid about not breaking backwards-compatibility. Perhaps we could bring them into the discussion to hear some of the things that they look for when maintaining compatibility. In the Java world, there is no binary-compatibility, for instance, but API compatibility is of course essential. > I don't have any specific examples that I can think of right now > other than the update from 8.0 to 8.5 removing BIO. That's a new major release of Tomcat, though. We ought to be able to break whatever we want, there. I think complaints about lack of backward-compatibility are unwarranted in this particular case. For the most part, Tomcat devs tend to feel free to modify completely-internal APIs as necessary, but will make an effort to maintain backward-compatibility for semi-internal APIs. It might be a good exercise to identify which parts of Tomcat should be considered (publicly) stable and which parts are okay to modify. Backward-compatibility is relatively easy in Java for certain things. Major refactorings usually don't happen in a point-release. - -chris [1] http://events.linuxfoundation.org/events/apachecon-north-america/program /cfp -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYd+dpAAoJEBzwKT+lPKRY33kP/AhgdrtshBuHzdBSqryIJXho 1FmWOO26LzO8TivH/hrcioo6hgMCXP5I/YWYJ+PH9BYwVAbzMZehW+8+9bfq07Ug RZGzJo7Xv/J9xmEsZsIki5wnOLYVG+M80ZCLCGo80YEduQyhbnITvfH32D6jlLZc k8A8NGA+Gldyq+Rc+H2ZYnn7nbdgu2Tmk/5JrEUV34e3DD0fhKxr8DAJf6BbmcZ6 BhZ2CqtK1ePa5RfKxLXaf9CVqkTan/9tGTA3mMRzTe6nMsDGr3SascYX4T9kf7OH X38c4LpddImdxL3i4gC11V/NGpNFJ8nkD6CRodWDUcqPRkjnxNQ/w9vEA2NL3feu MjV83pHy6Ow8S9MtRge3VBDEynwHQ/y9UaCw5gbjnSSCkSbCxrgtVvLgod/hHKTs Ru5vf/SVYS7spyawscQCadR/ehp6WBWx1SnfjMZsgFdmpWPl3Xy8puwonDkJSfd9 52PRV+9XiBWnHTPgwPGuktfMWhMKW9CON8I4WYEQANNyM447tRWnwEzpva+oysam s/rgXafxD9FVJuvIL41+VzUv42XcTs6sT548TaXmUapDYo29vMZB0AHevPvNHfm6 52Nhc9YRrgS9CqU/tdQIQBTqttr2h/lwzw+cS7XxRakXPOKPFzF/rbgAyQaRkZyW vhHRawolld3jjohm+OEr =w1b6 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
