Re: [Jakarta Wiki] Update of "OneCommunityProposals" by StephenColebourne
On Mon, 2006-03-13 at 23:48 +0100, Andrew C. Oliver wrote: > > that'd only leaves POI in jakarta > > did you have a point there? :-) thanks for highlighting my bad grammar (it's past my bed time) the point was the bit you snipped :) preserving jakarta as a special umbrella for poi seems more than a little odd to me. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of "OneCommunityProposals" by StephenColebourne
that'd only leaves POI in jakarta did you have a point there? :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of "OneCommunityProposals" by StephenColebourne
On Sun, 2006-03-12 at 23:32 +0100, Andrew C. Oliver wrote: > 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. you've just an excellent argument for moving poi to top level :) like it or not, it's the jakarta pmc which has the binding votes. henri's proposal only formalises and organises the actual current state of affairs. if you don't trust my judgement enough to allow me a veto on poi commits then you need to talk to the other poi committers about graduating poi to top level status. > 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/). hmmm... commons, taglibs, http components and whatnot going to commons.apache.org that'd only leaves POI in jakarta: does that really make more sense than apache poi? - robert - 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: [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]
[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: [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]
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 gr
[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]