Re: New Spring Maintenance policy
On 24.09.2008 00:00, Sylvain Wallez wrote: Yeah. I read this as 3 months after release n+1 is out, release n becomes closed source. I'm wondering how long it will take for forks to appear that will provide open source bug fixes to old releases. I don't think that's n+1 but n: After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. They wouldn't talk about initial stability issues anymore if it were n+1. Joerg
Re: New Spring Maintenance policy
Hi, yes, all the wording is quite confusing. The statement cited by Peter is trying to convince readers into believing it will affect only old releases, but there nowhere is a guarantee put up that there will be a new release within the 3month period. And the policy puts up that 3 month period per release without referring to later releases. A clear statement along only the most current release will receive maintenance efforts would have been much easier and clearer (and would get broader acceptance by the community). That the whole thing was not put that way contributes to the impression that users should be convinced into a support contract. Rainer Joerg Heinicke schrieb: On 24.09.2008 00:00, Sylvain Wallez wrote: Yeah. I read this as 3 months after release n+1 is out, release n becomes closed source. I'm wondering how long it will take for forks to appear that will provide open source bug fixes to old releases. I don't think that's n+1 but n: After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. They wouldn't talk about initial stability issues anymore if it were n+1. Joerg
Re: Help with Continuations
Joerg Heinicke wrote: On 23.09.2008 13:39, Jeremy Quinn wrote: I don't see any way of working around this. What a shame, I guess this rules out putting this functionality into a system-level sitemap. That's actually by intention and used to be different. It was Leszek who changed it [1]. One very good reason [2] is the wrong context in a different interpreter and so sitemap. Links wouldn't be resolved correctly anymore. Joerg [1] http://svn.apache.org/viewvc?view=revrevision=106089 [2] http://marc.info/?l=xml-cocoon-devm=110268944032541w=4 I am afraid this cannot be changed. It used to be different but it was very error prone. Invoking continuations in different context than they were created led to unexpected (usually erroneous) results. I am always amazed how you guys are able to dig out some info in messages from 2004 :). -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: New Spring Maintenance policy
Joerg Heinicke wrote: On 24.09.2008 00:00, Sylvain Wallez wrote: Yeah. I read this as 3 months after release n+1 is out, release n becomes closed source. I'm wondering how long it will take for forks to appear that will provide open source bug fixes to old releases. I don't think that's n+1 but n: After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. They wouldn't talk about initial stability issues anymore if it were n+1. Wow, that's even worse... Sylvain -- Sylvain Wallez - http://bluxte.net
[C2.2] Why two sets of HTML serializers?
I've been examining the HTMLSerializer so that I can document it on Daisy. Initially, I was confused about what config options could be used and then it dawned on me that there are actually two different implementations! The default is to use: o.a.c.serialization.HTMLSerializer but there is another one called: o.a.c.components.serializers.HTMLSerializer I'm assuming that this second version is an attempt to move away from depending on Xalan for outputting HTML. I also note that it makes life easier for users by implementing a 'doctype-default' config setting which takes 'strict', 'loose', 'frameset' or 'compatible' as values. I've perused the developer mail archive and the svn log but not found anything about the background for this second implementation. Could someone just confirm that I'm on the right track. Is the intention to make the second implementation the default at some point? What other advantages does this new version have? Regards, David Legg
Re: New Spring Maintenance policy
Sylvain Wallez wrote: Joerg Heinicke wrote: On 24.09.2008 00:00, Sylvain Wallez wrote: Yeah. I read this as 3 months after release n+1 is out, release n becomes closed source. I'm wondering how long it will take for forks to appear that will provide open source bug fixes to old releases. I don't think that's n+1 but n: After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. They wouldn't talk about initial stability issues anymore if it were n+1. Wow, that's even worse... That move is probably plain stupid. Rod Johnson states that the full source tree will still be available - there will be simply no public releases after 3 months and no svn tags to build that release yourself. You will only be able to build snapshots (better said internal releases) to address the issues you encounter. Yet again: plain stupid. Every open source project will have to track it's spring version by its own. How will the project be able to report issues if 99% of the world will be using snapshots? My spring version r144554 shows some problem? Clearly this is very short sighted. It is even more insulting to the comunity stating that it is too costly for SpringSource to do 'mvn deploy' from time to time. It's just a marketing version of Buy a damn subscription!. There's an quick and easy way to force users to subscription: just make major releases less frequent. If you haven't read on TSS: Although the prices are not publicly known someone stated that yearly subscription is something about $16 000... lg -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: New Spring Maintenance policy
Hi, There is a worst case scenario now: What if they don't collect enough money from subscriptions and do the next step: remove the 3 months window or worse go full closed source? I think changing the rules is not fair at all. That should rings our bells. Most important, our own user base will suffer. Any of our user now have to have in the pocket 16k yearly in order to deploy a cocoon 2.2 based application. That does not sounds good at all. There are many ways to describe the spirit of the apache community, but there is one that I like more than all the others: 'we care about people more than we care about code'. We have to do something. Best Regards, Antonio Gallardo. Antonio Gallardo escribió: Hi folks, Perhaps an old news for some, but I would like to know how you guys think this affects cocoon: http://www.theserverside.com/news/thread.tss?thread_id=50727 Are we going to take some actions on that? Best Regards, Antonio Gallardo.
Re: New Spring Maintenance policy
On Wed, Sep 24, 2008 at 10:10 AM, Antonio Gallardo [EMAIL PROTECTED] wrote: Hi, There is a worst case scenario now: What if they don't collect enough money from subscriptions and do the next step: remove the 3 months window or worse go full closed source? I think changing the rules is not fair at all. That should rings our bells. Most important, our own user base will suffer. Any of our user now have to have in the pocket 16k yearly in order to deploy a cocoon 2.2 based application. That does not sounds good at all. There are many ways to describe the spirit of the apache community, but there is one that I like more than all the others: 'we care about people more than we care about code'. We have to do something. I'm not convinced that anything needs to be done at the moment. I don't like what they've done but I also don't think they are stupid, they are not going to piss off their entire user base. I'd suggest we simply continue to watch what happens for the next three months (at least) before we conclude that any action is necessary. If at that point we see real problems it won't be too late, we should still have a stable base that can continue to work for another 6 months or so. At this point maybe the best thing to do is scope out possible directions to head if this does indeed turn out to be an issue? -- Peter Hunsberger
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (108 issues) Subscriber: cocoon Key Summary COCOON-2233 Update archetypes to current trunk artifact versions https://issues.apache.org/jira/browse/COCOON-2233 COCOON- Add SaxParser configuration properties https://issues.apache.org/jira/browse/COCOON- COCOON-2217 HttpServletResponseBufferingWrapper throws NPE when response body is empty https://issues.apache.org/jira/browse/COCOON-2217 COCOON-2216 IncludeCacheManager can not perfom parallel includes https://issues.apache.org/jira/browse/COCOON-2216 COCOON-2212 jx:attribute does not check name is correct before proceeding https://issues.apache.org/jira/browse/COCOON-2212 COCOON-2211 Support for jx:element https://issues.apache.org/jira/browse/COCOON-2211 COCOON-2210 The field 'type' in GenerateNode in corona-sitemap should not be final https://issues.apache.org/jira/browse/COCOON-2210 COCOON-2197 Making the cocoon-auth-block acegi-security-sample work https://issues.apache.org/jira/browse/COCOON-2197 COCOON-2173 AbstractCachingProcessingPipeline: Two requests can deadlock each other https://issues.apache.org/jira/browse/COCOON-2173 COCOON-2162 [PATCH] Fix for Paginator when accessing out of bounds Pagination page https://issues.apache.org/jira/browse/COCOON-2162 COCOON-2137 XSD Schemas for CForms Development https://issues.apache.org/jira/browse/COCOON-2137 COCOON-2114 fix sorting in TraversableGenerator https://issues.apache.org/jira/browse/COCOON-2114 COCOON-2108 xmodule:flow-attr Does not accept document objects https://issues.apache.org/jira/browse/COCOON-2108 COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer https://issues.apache.org/jira/browse/COCOON-2104 COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow https://issues.apache.org/jira/browse/COCOON-2100 COCOON-2071 Option to turn off pooling for components (probably faster on new JVMs and simpler debugging) https://issues.apache.org/jira/browse/COCOON-2071 COCOON-2041 WebDAV Returns improper status on PUT https://issues.apache.org/jira/browse/COCOON-2041 COCOON-2040 Union widget does not work with booleanfield set as case widget https://issues.apache.org/jira/browse/COCOON-2040 COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type=checkbox https://issues.apache.org/jira/browse/COCOON-2030 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the servlet protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for generator/reader already set should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early https://issues.apache.org/jira/browse/COCOON-1943 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or
Re: New Spring Maintenance policy
On Wed, 2008-09-24 at 09:10 -0600, Antonio Gallardo wrote: Hi, There is a worst case scenario now: What if they don't collect enough money from subscriptions and do the next step: remove the 3 months window or worse go full closed source? How people feel to create a spring fork here on the ASF and we can make sure that we will not have this problem in the future? salu2 I think changing the rules is not fair at all. That should rings our bells. Most important, our own user base will suffer. Any of our user now have to have in the pocket 16k yearly in order to deploy a cocoon 2.2 based application. That does not sounds good at all. There are many ways to describe the spirit of the apache community, but there is one that I like more than all the others: 'we care about people more than we care about code'. We have to do something. Best Regards, Antonio Gallardo. Antonio Gallardo escribió: Hi folks, Perhaps an old news for some, but I would like to know how you guys think this affects cocoon: http://www.theserverside.com/news/thread.tss?thread_id=50727 Are we going to take some actions on that? Best Regards, Antonio Gallardo. -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: New Spring Maintenance policy
On 24.09.2008 17:10, Antonio Gallardo wrote: There is a worst case scenario now: What if they don't collect enough money from subscriptions and do the next step: remove the 3 months window or worse go full closed source? Spring is released with Apache 2 license so we are free to grab and host a fork if it will be necessary. I think changing the rules is not fair at all. That should rings our bells. Most important, our own user base will suffer. Any of our user now have to have in the pocket 16k yearly in order to deploy a cocoon 2.2 based application. That does not sounds good at all. Of course it's a Bad Thing, but they are free to do so and we have to live with it. As it looks now it's gonna be alright. There are many ways to describe the spirit of the apache community, but there is one that I like more than all the others: 'we care about people more than we care about code'. We have to do something. No idea how the one relates to the other :) But I oppose immediate actions. I wrote I really wonder if they are gonna keep up the policy in the state it is right now. And even if there is no reason for immediate actions since it still works. We just have to go from one major release to the next one (which is actually minor) without a lots of intermediate patch releases. Joerg
Re: New Spring Maintenance policy
Thorsten Scherler wrote: On Wed, 2008-09-24 at 09:10 -0600, Antonio Gallardo wrote: Hi, There is a worst case scenario now: What if they don't collect enough money from subscriptions and do the next step: remove the 3 months window or worse go full closed source? How people feel to create a spring fork here on the ASF and we can make sure that we will not have this problem in the future? You do realize that some ASF board members are employed by SpringSource, right? Ralph
