> 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.
That sounds good to me. I'll put something together and submit as soon as I can after checking with other maintainers to see if they're interested. > 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. That would be interesting. I'll try and chase up some of the complaints that I've heard recently to see if I can bring them to the list and sort them out. > 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. I'm not sure I agree with that (and I'm positive that other groups don't because I've heard complaints). It's the same major version (8), just a minor version update so the general expectation is that there aren't any breaking changes. If we were talking about the difference between 8 and 9, then sure we can do whatever is necessary as long as things were properly deprecated, etc. On Thu, Jan 12, 2017 at 3:30 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
