Re: Other Jakarta Components
On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: On Tue, 7 Mar 2006, Thomas Dudziak wrote: On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would point back to Jakarta for a dependency on [pool], but that helps to foster intra-project involvement. Betwixt, Digester and JXPath strike me as a bit more to swallow and XML might not want to taking such bites. You want to go ahead and ask them? Well, yes, JXPath migh be a bit much, but Digester and Betwixt IMO would fit nicely. And obviously the component developers should agree first whether they think this is a good idea. And if they are interested, I can ask the DB PMC if they agree, as well. I don't think there is any active maintenance for DbUtils, and I suspect not for DBCP either. I've been meaning to do some work on DbUtils - but I have a long list of those. However, I have no direct connections to XML PMC, and since I'm not an comitter on Digester/Betwixt/JXPath, it would feel a bit strange to me (though I would if you want me to). Go ahead and propose each one (db and xml) separately on commons-dev. See if anyone speaks up against it - I suspect you'll find that for betwixt/jxpath/dbutils/dbcp there won't be a huge amount of talk, though Struts uses digester (I think) and they might have an opinion (they're well represented on commons-dev). Yes, Struts uses Digester. It also uses BeanUtils, Chain, FileUpload, IO, Logging and Validator. I think this whole thing is putting the cart before the horse. You're in the process of destroying Commons, not just dismantling it, and for no good reason that I can see. The people involved with Digester should be the ones to initiate a discussion about whether or not they want to take Digester elsewhere. As it is, this is coming across more like why don't you guys go away, somewhere far away, 'cos we think that's a good idea. Stephen's proposal for Jakarta Language Components came from inside that grouping. So should any other proposals for groupings or departures. With respect to departures in particular, there is a serious potential for losing community. For example, I keep tabs on a bunch of different Commons components, primarily because all of the discussions happen on communal lists. If Digester and DbUtils, for example, go to some other community where they also share lists, I am very unlikely to sign up for those lists just to keep tabs on those components. Maybe the developers will move, but how much of the community will go with them? -- Martin Cooper We're only going to end up with a Jakarta XML Components at this rate; which would suck. The DB ones would either be in a Jakarta SQL Components (suck) or a Jakarta Enterprise Components. The latter isn't so bad, but as Geronimo shows - there's a lot in J2EE and I suspect that grouping would balloon. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would point back to Jakarta for a dependency on [pool], but that helps to foster intra-project involvement. Betwixt, Digester and JXPath strike me as a bit more to swallow and XML might not want to taking such bites. You want to go ahead and ask them? Martin Cooper wrote: I think this whole thing is putting the cart before the horse. You're in the process of destroying Commons, not just dismantling it, and for no good reason that I can see. The people involved with Digester should be the ones to initiate a discussion about whether or not they want to take Digester elsewhere. As it is, this is coming across more like why don't you guys go away, somewhere far away, 'cos we think that's a good idea. +1. I believe there is the potential to group Jakarta around perhaps 4 or 5 mailing lists groupings instead of 15+ now. But it cannot be forced. Just because db-commons and xml-commons exist doesn't mean that we should 'outsource' to them. OSS isn't like that. As I've said before, its in our nature as programmers to look for abstractions and hierarchies - to look for order. Community isn't that convenient. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On Sun, 2006-03-12 at 12:38 -0800, Martin Cooper wrote: On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: Yes, Struts uses Digester. It also uses BeanUtils, Chain, FileUpload, IO, Logging and Validator. I think this whole thing is putting the cart before the horse. You're in the process of destroying Commons, not just dismantling it, and for no good reason that I can see. The people involved with Digester should be the ones to initiate a discussion about whether or not they want to take Digester elsewhere. As it is, this is coming across more like why don't you guys go away, somewhere far away, 'cos we think that's a good idea. I'm a committer on commons-digester, and don't mind Henry or others discussing these topics at all. The pot of ideas needs a good stir from time to time (and Henry is a good stirrer :-). I do see some merit in having digester involved more with the xml crowd in the xml project. However I would currently think the disadvantages outweigh the advantages. In particular: * Digester is really pretty stable. There is no great demand for new features from users, and not many outstanding issues. * The package names org.apache.commons.digester would be odd for a component in the xml umbrella, but there's just NO reason to force a package name change on users. * As Martin says, there already exists a community here. There is *enough* support available at the moment in commons for Digester's stable needs. So while I'm +1 for taking a look at each existing commons component to determine *if* there might be a better home for it, I'm -0 to moving Digester. I *will* have a think about whether Digester 2.x would be better off in the xml project. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On 3/12/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 12 Mar 2006, Stephen Colebourne wrote: DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would point back to Jakarta for a dependency on [pool], but that helps to foster intra-project involvement. Betwixt, Digester and JXPath strike me as a bit more to swallow and XML might not want to taking such bites. You want to go ahead and ask them? Martin Cooper wrote: I think this whole thing is putting the cart before the horse. You're in the process of destroying Commons, not just dismantling it, and for no good reason that I can see. The people involved with Digester should be the ones to initiate a discussion about whether or not they want to take Digester elsewhere. As it is, this is coming across more like why don't you guys go away, somewhere far away, 'cos we think that's a good idea. +1. I believe there is the potential to group Jakarta around perhaps 4 or 5 mailing lists groupings instead of 15+ now. But it cannot be forced. Right. My first response was that we needed to be sure community would go with them. My gut instinct is that the DB ones would go - there's somewhat of an overlap between db.apache and commons, but I'm not convinced the XML ones would. Asking the question on commons-dev should initiate discussion with those who care about Digester - ideally asking it here would too but they might not be paying attention I guess. Waiting for every individual codebase to individually decide to get active and discuss non-code issues is a non-starter from the beginning. Why? Just because db-commons and xml-commons exist doesn't mean that we should 'outsource' to them. OSS isn't like that. That's no reason to ignore the idea though. OSS is sometimes like that. As I've said before, its in our nature as programmers to look for abstractions and hierarchies - to look for order. Community isn't that convenient. This still comes down to the basic issue :) I believe that as Thomas is a Jakarta committer it is not an idea being forced from the outside, but something from the inside. As he's a DB PMC member, then at least half is very much from the inside - and I think he was involved in the Commons SQL - DdlUtils move. Even in the model where we only look to those with substantial commits to a codebase - some of the inactive ones are going to be left behind and will need someone to be suggesting a direction for them. Why? -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of OneCommunityProposals by StephenColebourne
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by StephenColebourne: http://wiki.apache.org/jakarta/OneCommunityProposals The comment on the change is: Create page for one community proposals New page: This document proposes ways that we as Jakarta can move towards becoming one community rather than many. ''Note that there is a counter-argument that states that multiple communities within Jakarta is fine. However, at present this conflicts with the ASF board opinion and legal structure.'' == Mission == Jakarta has a less than completely clear mission at the moment. Here is a proposed 'mission statement', please feel free to make alternate suggestions: ''Jakarta provides a diverse set of Java-based components which aim to make day-to-day development easier. The focus is on reusable, small-scale, single-purpose libraries that can be used directly by your application or by larger frameworks.'' It would seem appropriate for whatever mission we choose to be on the top of the Jakarta home page. == Maililng lists == Jakarta has about 16 current project mailing lists. One is very active (commons) and the rest vary from some activity to very little. Mailing lists are significant as they represent the primary means of communication in a project, and thus the primary form of community. Any change to mailing list structure needs careful consideration. The aim of any change is to create better oversight of the mature components. A 'one community' proposal must provide a technique to reduce the mailing list silo effect, where developers are not interested in other lists (and thus other parts of the same community). == Subversion access == Jakarta currently gives out SVN access to individual subprojects. A 'one community' proposal almost certainly involves removing this barrier. Any Jakarta committer can thus commit anywhere in Jakarta. Social norms will still act as a barrer to undesirable behaviour. == Subprojects == As developers we tend to abstract and form hierarchies naturally. Subprojects are a natural outcome of this. However, Jakarta as 'one community' must mean the end to the term 'subprojects'. Instead, a focus on many, many components directly at the Jakarta level is the best viewpoint. == Practicalities == The single-level groupings proposal. Theory - One community split into groups for practicality purposes (everyone together would be chaos!) * Move all commons proper projects up to the jakarta level in SVN and on the website. * Commons level infrastructure/pages is dismantled and moved to jakarta-level * Agree on 4 to 5 groupings for the current subprojects (this is hard!!! it should ideally be driven by the current component owners) * The groupings should have bland names - they are not subprojects * The commons-sandbox moves to be a jakarta concept * Provide a mailing list for each of the groupings * Redfine the Jakarta home page to display all the components in Jakarta using the groupings as a navigation aid * Use a single mailing list to discuss cross jakarta issues, such as maven builds etc. This may be jakarta-general or a new jakarta-dev * No SVN commit restrictions across groups The aim is for each grouping to be large enough to avoid inactivity, but small enough to be manageable and to foster community. The proposal also aims to encourage a significant percentage of developers to be in more than one grouping. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of OneCommunityProposals by StephenColebourne
I'd like to note my opposition. I don't have the same vision as you do and do not wish to be distracted by 100 irrelavant emails a day about Commons ABCD. I'm glad Henri posted that reorganization things were being discussed. I would have preferred that he posted a more detailed message as I think others would likely be opposed to such forms of social engineering. Things evolve the way the evolve for a reason. That POI has relatively little to do with Commons-DB is not really a good reason to force us to listen to noise/interference. In radio, you tend to try and pick bands that aren't real close together so that you don't overlap and trample on each other's bandwidth. I had to do this with my wireless network because my neighbor's stuff kept interferring. No I don't think it would be great if we both shared channel 6 and I don't feel like vetting some non-technical irrelevant change by someone who wanted to get their API used by more projects (nevermind that it performs half as well as the JDK implementation and sucks down 100 other dependencies). And I bet [EMAIL PROTECTED] would be REALLY popular...so popular that ALL questions about POI would go to [EMAIL PROTECTED] with CC to every email address I've ever had and appologies for not posting on the list but half the time you can't unsubscribe and I really don't want 1 emails a day about stuff I'm not using. If projects share obvious common technical ties then it makes sense, otherwise lets let darwin decide rather than radical social engineering. The PMC should ASK the individual projects if they would like to share a common list and set of committers rather than a top down decision proposed on a list that most committers don't subscribe to (which might indicate...duh...that they don't want to be on a list mostly not about their project). This proposal and any that resemble it are non-starters for me. A lot of this sounds like Commons trying to remake Jakarta in its image. As an alternative why can't commons be top level? The namespace is now free (http://commons.apache.org/). That is all, -Andy Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by StephenColebourne: http://wiki.apache.org/jakarta/OneCommunityProposals The comment on the change is: Create page for one community proposals New page: This document proposes ways that we as Jakarta can move towards becoming one community rather than many. ''Note that there is a counter-argument that states that multiple communities within Jakarta is fine. However, at present this conflicts with the ASF board opinion and legal structure.'' == Mission == Jakarta has a less than completely clear mission at the moment. Here is a proposed 'mission statement', please feel free to make alternate suggestions: ''Jakarta provides a diverse set of Java-based components which aim to make day-to-day development easier. The focus is on reusable, small-scale, single-purpose libraries that can be used directly by your application or by larger frameworks.'' It would seem appropriate for whatever mission we choose to be on the top of the Jakarta home page. == Maililng lists == Jakarta has about 16 current project mailing lists. One is very active (commons) and the rest vary from some activity to very little. Mailing lists are significant as they represent the primary means of communication in a project, and thus the primary form of community. Any change to mailing list structure needs careful consideration. The aim of any change is to create better oversight of the mature components. A 'one community' proposal must provide a technique to reduce the mailing list silo effect, where developers are not interested in other lists (and thus other parts of the same community). == Subversion access == Jakarta currently gives out SVN access to individual subprojects. A 'one community' proposal almost certainly involves removing this barrier. Any Jakarta committer can thus commit anywhere in Jakarta. Social norms will still act as a barrer to undesirable behaviour. == Subprojects == As developers we tend to abstract and form hierarchies naturally. Subprojects are a natural outcome of this. However, Jakarta as 'one community' must mean the end to the term 'subprojects'. Instead, a focus on many, many components directly at the Jakarta level is the best viewpoint. == Practicalities == The single-level groupings proposal. Theory - One community split into groups for practicality purposes (everyone together would be chaos!) * Move all commons proper projects up to the jakarta level in SVN and on the website. * Commons level infrastructure/pages is dismantled and moved to jakarta-level * Agree on 4 to 5 groupings for the current subprojects (this is hard!!! it should ideally be driven by the current component owners) * The
Re: Subproject Charters
On Sun, 2006-03-05 at 17:31 -0500, Henri Yandell wrote: On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: snip Say some Prolog constraint framework decided it wanted to be part of Commons. Where would you point them to explain that that's not what Commons is about? The Jakarta charter where it says Java (which in fact it doesn't say - might be a bit of an ommission). OK, then what about a Java constraint framework? If it's large: -1 to Commons, -1 to Jakarta. If it's tiny +0 to Commons, +1 to Jakarta, but they're converging to both be a +1 if not too framework like. I specifically chose a framework for my example because we have long stated that frameworks should not live in Commons, and that is stated in our charter. Are you saying you want to change that now, to allow frameworks as Commons components? I so, -1 from me. Other way, frameworks -1 to being within Jakarta. Depends on definition of framework - VFS is a framework to me; an interface structure designed for multiple implementations. I'd stay +1 for small things like VFS. IMO VFS is a bridging library, not a framework. bridging libraries have a simple, user facing API is intended to be used as a standard library. they also have a SPI (typically a mini-framework) to allow the library to be extended by adding new implementations. normal users should never use this: they just use it as a normal library. there are actually a number of bridging APIs in the commons and some more are in the sandbox (for example, proxy). they are small and useful for library creators since they allow projects to support multiple backend configurations. bridging APIs have a number of similarities and would probably make sense as a grouping. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of OneCommunityProposals by StephenColebourne
For the record, I wrote this to try to sum up where discussions have got to and to provide some vision as to where the end result might be. Checking mailing lists tonight indicates that POI has quite a healthy set of messages as is. I didn't see much development discussion (an indicator of community) but I could be mistaken. IMO, a *forced* merger of POI with another group would have very negative consequences, both for POI and the other group. Sorry I wasn't clear on that. At the moment, I see this debate as not affecting POI. (It also probably excludes Hivemind and possibly some other subprojects). IMHO, this debate is about commons and the inactive/mature Jakarta subprojects. Andrew C. Oliver wrote: A lot of this sounds like Commons trying to remake Jakarta in its image. As an alternative why can't commons be top level? The namespace is now free (http://commons.apache.org/). or why not http://poi.apache.org/ ;-) Then you don't have to listen to our debates. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of OneCommunityProposals by StephenColebourne
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by StephenColebourne: http://wiki.apache.org/jakarta/OneCommunityProposals The comment on the change is: Add 'no forced merger' clause -- * Move all commons proper projects up to the jakarta level in SVN and on the website. * Commons level infrastructure/pages is dismantled and moved to jakarta-level - * Agree on 4 to 5 groupings for the current subprojects (this is hard!!! it should ideally be driven by the current component owners) + * Agree on 4 to 5 groupings for the current subprojects (this is hard!!! it should ideally be driven by the current component owners)$ * The groupings should have bland names - they are not subprojects * The commons-sandbox moves to be a jakarta concept * Provide a mailing list for each of the groupings @@ -45, +45 @@ * Use a single mailing list to discuss cross jakarta issues, such as maven builds etc. This may be jakarta-general or a new jakarta-dev * No SVN commit restrictions across groups + $ No existing mailing list/community should be forced into a merger that they are dead set against. This would be bad for both sides of the merger. + The aim is for each grouping to be large enough to avoid inactivity, but small enough to be manageable and to foster community. The proposal also aims to encourage a significant percentage of developers to be in more than one grouping. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
Martin Cooper wrote: snip/ I think this whole thing is putting the cart before the horse. You're in the process of destroying Commons, not just dismantling it, and for no good reason that I can see. The people involved with Digester should be the ones to initiate a discussion about whether or not they want to take Digester elsewhere. As it is, this is coming across more like why don't you guys go away, somewhere far away, 'cos we think that's a good idea. Stephen's proposal for Jakarta Language Components came from inside that grouping. So should any other proposals for groupings or departures. With respect to departures in particular, there is a serious potential for losing community. For example, I keep tabs on a bunch of different Commons components, primarily because all of the discussions happen on communal lists. If Digester and DbUtils, for example, go to some other community where they also share lists, I am very unlikely to sign up for those lists just to keep tabs on those components. Maybe the developers will move, but how much of the community will go with them? I agree strongly with the points above. I am +1 for jlc but -1 for engineered dissolution of j-c. The key point is that movement needs to be driven by people who want to move. Consider these two specific examples: [naming] - we decided on ontological grounds to move this to Directory some time ago. We were never able to build a community around it there, the Directory community had no interest in it, and it has gone nowhere. Of course, it may have gone nowhere in j-c as well, and its stalling could all just be lack of vision / ability to get tomcat to go along, but I can't help thinking that it would have done better off staying in j-c. [dbcp] - suppose some grand scheme had already moved it to DB. Would volunteers there now be stepping up to maintain it now? If the move to DB was initiated by community members who really wanted to drive it, then the answer would likely be yes. That is the key point. There have been *many* examples over the years of j-c community members stepping up to contribute to components that they were not involved in when they started at the commons. There is also tremendous value in the collective oversight, both technical and community / legal, that happens in j-c. We should think very carefully before dissolving that community. Phil Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of OneCommunityProposals by StephenColebourne
On Sun, 12 Mar 2006, Andrew C. Oliver wrote: I'm glad Henri posted that reorganization things were being discussed. I would have preferred that he posted a more detailed message as I think others would likely be opposed to such forms of social engineering. Things evolve the way the evolve for a reason. That POI has relatively little to do with I didn't post more because I didn't want to falsely represent Martin, Stephen and many others' viewpoints. Best to read the originals I figure. If projects share obvious common technical ties then it makes sense, otherwise lets let darwin decide rather than radical social engineering. This is a point many have brought up (Martin, Stephen, yourself). Let evolution take care of it. It's a cool saying to use. Unfortunately it's a terrible metaphor. Evolution happens in spontaneous bursts, and via mutations that allow some to be better suited to environmental change. Not because the whole decide to change their ways. This is evolution happening right now. What you mean to say is let's not change. [I fully accept I don't get evolution, it's a moving target of a subject - but I'm closer than the previous metaphor] The PMC should ASK the individual projects if they would like to share a common list and set of committers rather than a top down decision proposed on a list that most committers don't subscribe to (which might indicate...duh...that they don't want to be on a list mostly not about their project). This proposal and any that resemble it are non-starters for me. What it indicates is that they are not a part of the Jakarta community. The viewpoint that I am an ECS committer, not a Jakarta committer has only one answer to my view - ecs.apache.org. A lot of this sounds like Commons trying to remake Jakarta in its image. As Nope, much of this is me trying to turn Jakarta into a normal Apache project - rather than the corpse of something that was determined to be unwanted by the ASF as a whole many years ago. Jakarta was considered in need of change back then and thus the TLPs started happening, and we're less healthy now than we were then. Given that Commons defines a much healthier umbrella concept than Jakarta does, I'm seeking to bring those ideas up into Jakarta while flattening the whole so we're less of a 3 to 4 tier umbrella. an alternative why can't commons be top level? The namespace is now free (http://commons.apache.org/). It's definitely another option - and one I've mentioned. The namespace is pretty much free - a few views that we shouldn't be re-using an old name but I'm confident we'd be able to use the name. One point likely to cause trouble is over whether commons.apache.org would be Java focused or not. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On Sun, 12 Mar 2006, Martin Cooper wrote: On 3/12/06, Henri Yandell [EMAIL PROTECTED] wrote: Asking the question on commons-dev should initiate discussion with those who care about Digester - ideally asking it here would too but they might not be paying attention I guess. Waiting for every individual codebase to individually decide to get active and discuss non-code issues is a non-starter from the beginning. Why? Because some of them are so dead as to make that unlikely to happen. For example, we just voted to move Commons Latka into dormancy - how can we do that? Did the Latka community decide on that? We started discussing it and the Latka community could have spoken up. There's no difference here. The Jakarta community starts discussing, and those who feel the most affected by something can speak up. Even in the model where we only look to those with substantial commits to a codebase - some of the inactive ones are going to be left behind and will need someone to be suggesting a direction for them. Why? Unsure which this why is to, the first is the one above - inactive projects will just sit and do nothing because there is nobody to do anything. The second is that the Jakarta community is responsible for these projects, even if they are not actively committing in those projects; and so the Jakarta community needs to be discussing them. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of OneCommunityProposals by StephenColebourne
On Sun, 12 Mar 2006, Stephen Colebourne wrote: Checking mailing lists tonight indicates that POI has quite a healthy set of messages as is. I didn't see much development discussion (an indicator of community) but I could be mistaken. There's not a lot of conversation on poi-dev; though there is a healthy flow via bugzilla comments and occasional svn commits. IMO, a *forced* merger of POI with another group would have very negative consequences, both for POI and the other group. Sorry I wasn't clear on that. Agreed. At the moment, I see this debate as not affecting POI. (It also probably excludes Hivemind and possibly some other subprojects). IMHO, this debate is about commons and the inactive/mature Jakarta subprojects. Yup. Tapestry - TLP Slide - TLP (if they get active enough to do it) Cactus/JMeter - TLP (need to write a proposal) Turbine - Against TLP HiveMind - Just brought an email on TLP alive again. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On Mon, 13 Mar 2006, Henri Yandell wrote: On Sun, 12 Mar 2006, Martin Cooper wrote: On 3/12/06, Henri Yandell [EMAIL PROTECTED] wrote: Asking the question on commons-dev should initiate discussion with those who care about Digester - ideally asking it here would too but they might not be paying attention I guess. Waiting for every individual codebase to individually decide to get active and discuss non-code issues is a non-starter from the beginning. Why? Because some of them are so dead as to make that unlikely to happen. For example, we just voted to move Commons Latka into dormancy - how can we do that? Did the Latka community decide on that? We started discussing it and the Latka community could have spoken up. There's no difference here. The Jakarta community starts discussing, and those who feel the most affected by something can speak up. [Correction: Dion did just post a +1, he was once actively committing on Latka] Point remains though. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of JakartaBoardReport-March2006 by HenriYandell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta/JakartaBoardReport-March2006 The comment on the change is: Sending to the board -- - == March 2006 Board Report == + In progress of being sent to the board. - === Status === - - This quarter has been quiet on the release front - nothing for a month and a half - however there is a lot lining up for the next quarter. Reorganization discussions are underway on general@ and commons-dev@ mailing lists and Tapestry is now a TLP (with this becoming visible/enacted in the next quarter). - - Other subprojects are worthy of mention on the TLP subject. - - * Slide is in favour of moving to TLP, but lacks the activity to get there. - * Cactus/JMeter are in favour of proposing a testing.apache.org TLP to the board - though again low on activity. - * Turbine and Velocity are both against moving to TLP. One of those reasons is a lack of activity. - - In the next quarter I intend to make some time available to help get Slide and Cactus/JMeter to the point of a proposal. - - Follow up on last months issues - - * The Silk name has been dropped and will instead be called Jakarta Web Components. I could never get a solid answer on trademark handling. - * Inactivity. We continue to move forward in recognizing and labelling areas of inactivity. - - === Releases === - * 29 January 2006 - HiveMind 1.1.1 Released - * 07 January 2006 - Tapestry 4.0 (final) Released - * 28 December 2005 - Tapestry 4.0-rc-3 Released - * 23 December 2005 - Commons File``Upload 1.1 Released - * 20 December 2005 - Commons Math 1.1 Released - * 20 December 2005 - Commons Http``Client 3.0 Released - - === Community changes === - - New Committers - - * Dennis Lundberg - * Sandy !McArthur - * Max Pfingsthorn - * Jörg Schaible - - New PMC - - * Mario Ivankovits - * Rahul Akolkar - * Oliver Heger - * Siegfried Goeschl - - === Infrastructure news === - - Alexandria mailing list shut down. - - === Subproject news === - - Commons Configuration - Commons Configuration 1.2 was released in December 2005. This release mainly addressed some bugs related to file-based configurations and reloading strategies. There were only a few new features, e. g. a new configuration type or validation support in XMLConfiguration. At the moment work is in progress on some often requested features, especially support for XPATH syntax. So the next release will certainly be a feature release. - - Commons FileUpload - - After a protracted period of inactivity, FileUpload 1.1 was released just before Christmas 2005. Future work on FileUpload is targetted at a 2.0 release, with associated necessary API changes. - - Commons Net - Version 1.4.1 released in December 2005 to restore JDK 1.3 compatibility, enabling VFS to be released as JDK 1.3 compatible. - - Commons Math - Version 1.1 was released in December 2005. This release included numerous bug fixes and enhancements in the random data generation, numerics and matrix packages. - - Commons Validator - Validator 1.2.0 was released in November 2005. The main new piece of functionality in this version had been in place for some time, however it had been held up by the number of outstanding bugs. A concerted effort on bugs (non-enhancement) in the second half of 2005 made the 1.2.0 release possible and currently bugs are being tackled in a timely manner with a validator 1.2.1 maintenace release planned shortly. - - HiveMind - - HiveMind has released version 1.1.1, which was a bug fix release. Conceptual work for version 1.2 has started. - - HttpComponents - - With the stable release of HttpClient 3.0 a major milestone has been reached. At the same time development of the HttpClient 2.x branch is discontinued. 2.x users are encouraged to migrate. - - Roland Weber joined the team of committers. He is working hard on http-async. A lot of effort is going into the design of http-core and http-async currently. - - The content and design of new project website is shaping up. - - Tapestry - - - no report - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta January-March 2006 report (fwd)
Here's this quarter's report -- Forwarded message -- Date: Mon, 13 Mar 2006 02:32:32 -0500 (EST) From: Henri Yandell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Jakarta January-March 2006 report == March 2006 Board Report == === Status === This quarter has been quiet on the release front - nothing for a month and a half - however there is a lot lining up for the next quarter. Reorganization discussions are underway on general@ and commons-dev@ mailing lists and Tapestry is now a TLP (with this becoming visible/enacted in the next quarter). Other subprojects are worthy of mention on the TLP subject. * Slide is in favour of moving to TLP, but lacks the activity to get there. * Cactus/JMeter are in favour of proposing a testing.apache.org TLP to the board - though again low on activity. * Turbine and Velocity are both against moving to TLP. One of those reasons is a lack of activity. In the next quarter I intend to make some time available to help get Slide and Cactus/JMeter to the point of a proposal. Follow up on last months issues * The Silk name has been dropped and will instead be called Jakarta Web Components. I could never get a solid answer on trademark handling. * Inactivity. We continue to move forward in recognizing and labelling areas of inactivity. === Releases === * 29 January 2006 - HiveMind 1.1.1 Released * 07 January 2006 - Tapestry 4.0 (final) Released * 28 December 2005 - Tapestry 4.0-rc-3 Released * 23 December 2005 - Commons FileUpload 1.1 Released * 20 December 2005 - Commons Math 1.1 Released * 20 December 2005 - Commons HttpClient 3.0 Released === Community changes === New Committers * Dennis Lundberg * Sandy McArthur * Max Pfingsthorn * Jorg Schaible New PMC * Mario Ivankovits * Rahul Akolkar * Oliver Heger * Siegfried Goeschl === Infrastructure news === Alexandria mailing list shut down. === Subproject news === Commons Configuration Commons Configuration 1.2 was released in December 2005. This release mainly addressed some bugs related to file-based configurations and reloading strategies. There were only a few new features, e. g. a new configuration type or validation support in XMLConfiguration. At the moment work is in progress on some often requested features, especially support for XPATH syntax. So the next release will certainly be a feature release. Commons FileUpload After a protracted period of inactivity, FileUpload 1.1 was released just before Christmas 2005. Future work on FileUpload is targetted at a 2.0 release, with associated necessary API changes. Commons Net Version 1.4.1 released in December 2005 to restore JDK 1.3 compatibility, enabling VFS to be released as JDK 1.3 compatible. Commons Math Version 1.1 was released in December 2005. This release included numerous bug fixes and enhancements in the random data generation, numerics and matrix packages. Commons Validator Validator 1.2.0 was released in November 2005. The main new piece of functionality in this version had been in place for some time, however it had been held up by the number of outstanding bugs. A concerted effort on bugs (non-enhancement) in the second half of 2005 made the 1.2.0 release possible and currently bugs are being tackled in a timely manner with a validator 1.2.1 maintenace release planned shortly. HiveMind HiveMind has released version 1.1.1, which was a bug fix release. Conceptual work for version 1.2 has started. HttpComponents With the stable release of HttpClient 3.0 a major milestone has been reached. At the same time development of the HttpClient 2.x branch is discontinued. 2.x users are encouraged to migrate. Roland Weber joined the team of committers. He is working hard on http-async. A lot of effort is going into the design of http-core and http-async currently. The content and design of new project website is shaping up. Tapestry - no report - [chair] - Tapestry released the 4.0 release they've been building up to for 9 months or so; agreed on the move to TLP and are hard at work on 4.1. There's an interesting thread going on about whether to backport 4.1 fixes to 3.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of JakartaBoardReport-March2006 by HenriYandell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta/JakartaBoardReport-March2006 The comment on the change is: Board report process finished. -- - In progress of being sent to the board. + = Jakarta Report = + == March 2006 == + + Sent to the board and published at: [http://jakarta.apache.org/site/pmc/board-report-march2006.html] + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
