Re: New Spring Maintenance policy
On Wed, 2008-09-24 at 22:17 -0700, Ralph Goers wrote: 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? Meaning? I did not know but to be honest that should not influence whether the ASF would fork spring and secure that it keeps open. However let us see whether their keep this policy and how that influence us. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: New Spring Maintenance policy
Ralph Goers wrote:
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?
Should this have any influence on our decisions?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: New Spring Maintenance policy
Leszek Gawron wrote: 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. There's an easy way the OSS community can react to that: create an OpenSpring.org website that will provide official open source maintenance releases from well-known revisions of the SpringSource SCM. That way, people will be able to use e.g. openspring 2.4.8 which will actually be springsource r144554 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... Ouch. Spring was born as a lightweight and open source alternative to big and costly J2EE containers. It's now as big and costly (and as bloated?) as a J2EE container... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [C2.2] Why two sets of HTML serializers?
David Legg wrote:
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?
See http://cocoon.markmail.org/message/z63kh2sx3u4spxo7
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: [C2.2] Why two sets of HTML serializers?
Good call Reinhard, thanks! Reinhard Pötz wrote: I've perused the developer mail archive and the svn log but not found anything about the background for this second implementation. See http://cocoon.markmail.org/message/z63kh2sx3u4spxo No wonder I didn't find it... 2004 is ancient history ;-) Regards, David Legg
Re: New Spring Maintenance policy
First, let me say that I don't think the Spring policy is going to end up being as bad as it was made out to be at first glance, although that may just be wishful thinking. In any case, I think it is extremely premature to talk about forking the code. I think if you were to put yourself in the position where you were a happy employee of SpringSource looking to insure that your company stays healthy into the future, you would find it difficult to support the code being forked into the ASF. I certainly know I would. Although you'd probably like to think that what you do at the ASF is completely independent of your employer it is never really quite that simple. Reinhard Pötz wrote: Ralph Goers wrote: 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? Should this have any influence on our decisions?
Re: New Spring Maintenance policy
Ralph Goers wrote:
First, let me say that I don't think the Spring policy is going to end
up being as bad as it was made out to be at first glance, although that
may just be wishful thinking.
I have the same hopes but something tells me that it is only another
step into the direction of closed source :-(
In any case, I think it is extremely
premature to talk about forking the code.
yes it is, but I fear that we will see several forks because not
everybody will be eager to build Spring himself and put them into
internal repositories.
I think if you were to put yourself in the position where you were a
happy employee of SpringSource looking to insure that your company stays
healthy into the future, you would find it difficult to support the code
being forked into the ASF. I certainly know I would. Although you'd
probably like to think that what you do at the ASF is completely
independent of your employer it is never really quite that simple.
Sure, it wouldn't be easy for them but I guess that they would simply
abstain from all related decisions. (Except from lobbying against an ASF
fork of Spring they can't do anything else anyway because voting against
it wouldn't prevent anything AFAIU)
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: New Spring Maintenance policy
Rainer Pruy wrote:
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.
Thanks Rainer, that's more or less the same that I wanted to say. Maybe
SpringSource can be convinced to change their policy into this direction.
WDOT, would a petition help for that purpose?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: New Spring Maintenance policy
I'd doubt a petition by itself would make them change the policy. Probably they no longer can afford time, money or other resource to support community version of spring. If they are trying to make a business out of it it is quite obvious that they won't pop up asking for someone to take over. Nevertheless, It might help indicating to them that their behaviour might endanger any business perspective implied so that they are more willing to keep a sufficient level of support. I personally do think there is no need for immediate action. But in the worst case we will be in a similar situation as when the current team around spring had declared their retirement from spring project: A new team needs to take over. So let's have a close watch at further development of the issue Rainer Reinhard Pötz schrieb: Rainer Pruy wrote: 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. Thanks Rainer, that's more or less the same that I wanted to say. Maybe SpringSource can be convinced to change their policy into this direction. WDOT, would a petition help for that purpose? -- Rainer Pruy Geschäftsführer Acrys Consult GmbH Co. KG Untermainkai 29-30, D-60329 Frankfurt Tel: +49-69-244506-0 - Fax: +49-69-244506-50 Web: http://www.acrys.com - Email: [EMAIL PROTECTED] Handelsregister: Frankfurt am Main, HRA 31151
Application Period Opens for Travel Assistance to ApacheCon US 2008
Hi, The ApacheCon US 2008 conference is getting closer. If you are interested in participating but would have a hard time financing the trip, the Apache Travel Assistance Committee may be able to help you. See below for their announcement about the financial support that the Apache Software Foundation is making available to qualified developers. -Bertrand The Travel Assistance Committee is taking in applications for those wanting to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New Orleans. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon US 2008 who need some financial support in order to get there. There are VERY few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF and open source in general. Financial assistance is available for flights, accomodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in Europe and or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon US of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the application form and details for submitting. Time is very tight for this event, so applications are open now and will end on the 2nd October 2008 - to give enough time for travel arrangements to be made. Good luck to all those that will apply. Regards, The Travel Assistance Committee
