Re: Notice of intent.... #2
Tim OBrien wrote: --- Stephen Colebourne [EMAIL PROTECTED] For example: - HttpComponents - WebComponents - LibraryComponents (narrowAPI-deep) - BaseComponents (broadAPI-shallow) Explain that narrowAPI-deep, braodAPI-shallow business. BroadAPI-Shallow The principal API of the component is broad. That is, it consists of lots of methods. Each of those methods is Shallow. That is, each method does relatively little processing. Typically, these will not have config files. Typically, these wil not have dependencies. For example, a static Utils class. For example, commons-lang, commons-io. NarrowAPI-Deep The principal API of the component is narrow. That is, there are relatively few methods in the whole javadoc that most users should call. Each of those 'external' methods is Deep. That is, each external method performs a lot of internal work to achieve its goal. Typically, these will have config files. Typically, these wil have dependencies. For example, commons-jxpath, oro. I sugest these as groupings as I believe there is a difference in skills in creating these two types of libraries. With NarrowDeep its all about the making that narrow API as simple to understand, yet powerful, as possible. With BroadShallow, there is a lot of work defining the method exactly and in naming. (Plus lots of overap in skills too...) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
Phil Steitz wrote: Hopefully we can keep it at a point where the groups are really just there to refine the flow of mail, not to separate it. HttpComponents is an example of this (though not a good one as most of its components came from HttpClient). WebComponents (formerly hoped to be known as Silk) is another example. Commons would be groupalized out. Not sure I understand exactly what you mean here, but if it means breaking commons up - even the list - I think we should think very carefully about that. From what may be a selfish perspective - and which I will back off from if the rest of the community feels otherwise - I think getting feedback from the full group of commons committers and voluneers *really* helps those of us who work on commons components. I am afraid that if we break up the dev list and we don't all just agree to subscribe to all of the sublists (really defeating the purpose), we will both have a harder time building community around components and we will lose some valuable feedback. We will also have less collective energy to apply to things like the site, how we think about versioning and releases, etc. We are developing a pretty good body of collective experience developing small java components and I think that if we split up now we may be losing something. I believe that this plan only works if we are prepared to have multiple mailing lists. Try merging velocity, httpclient, taglibs,... all into the commons list and its just ridiculous. The question is how to break down the groupings. And how big should they be. One rule would be that a component is only in one grouping. For example: - HttpComponents - WebComponents - LibraryComponents (narrowAPI-deep) - BaseComponents (broadAPI-shallow) site and build discussions can occur on a shared list. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
--- Stephen Colebourne [EMAIL PROTECTED] wrote: For example: - HttpComponents - WebComponents - LibraryComponents (narrowAPI-deep) - BaseComponents (broadAPI-shallow) Explain that narrowAPI-deep, braodAPI-shallow business. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
Henri Yandell wrote: As a second email in the Notice of intent series; here's what I think being a Jakarta component will be like in the future. * Jakarta is a collection of components. Hopefully all sitting at the same level. ie) a big bag of things. How are you defining component? Something reusable? Something you build applications with? Something like a commons component? If that is the case, then Jmeter, Cactus, Velocity et al would have to go TLP. Is that part of the plan? * Groups exist. These are categorically not subprojects, but a way to allow for slicing of the website etc. Some groups may have their own mail list; thus the importance of making sure they don't become subprojects. An important rule will probably be that they must do votes on the main list. Hopefully we can keep it at a point where the groups are really just there to refine the flow of mail, not to separate it. HttpComponents is an example of this (though not a good one as most of its components came from HttpClient). WebComponents (formerly hoped to be known as Silk) is another example. Commons would be groupalized out. Not sure I understand exactly what you mean here, but if it means breaking commons up - even the list - I think we should think very carefully about that. From what may be a selfish perspective - and which I will back off from if the rest of the community feels otherwise - I think getting feedback from the full group of commons committers and voluneers *really* helps those of us who work on commons components. I am afraid that if we break up the dev list and we don't all just agree to subscribe to all of the sublists (really defeating the purpose), we will both have a harder time building community around components and we will lose some valuable feedback. We will also have less collective energy to apply to things like the site, how we think about versioning and releases, etc. We are developing a pretty good body of collective experience developing small java components and I think that if we split up now we may be losing something. Hopefully. Groupings are not vague names - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The idea with that being that boring grouping names are intentionally dull, no subcommunity identification. +1 - as we at least used to state in the commons charter ;-) * No svn authentication beyond being in the jakarta group. Velocity coders have rw access to POI. +1 * Improved Committer-PMC process. Chair's responsibility (I've failed at this so far) is to turn around the new committer process. A new committer of 6 months is effectively voted against going to the PMC, not for. Might not be able to make it exactly that way, but the idea being that joining the PMC is the exception, not the norm. Personally I'd like to see committership be removed if people repeatedly are not allowed onto the PMC. Not sure about this one. I am OK with kicking off the nomination more or less automatically, but would prefer that it be a postive vote. * Application of Commons thinking. Not entirely sure on this one as I think we've overcomplicated things in Commons a bit; but things like a common build system, common site system etc. * Sandbox becomes a Jakarta resource, not a Commons resource. Much of the same rules as it has currently. Probably a separate mailing list. I agree with Martin's comment on this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
On Wed, 11 Jan 2006, Will Glass-Husain wrote: Thanks, Henri. My feedback. Thanks, very useful stuff. * Generally positive with an aversion to anything involving significant work for the sake of a cleaner Jakarta. By this I mean that I like the idea of a flatter hierarchy and a clearer message to the public as to what Jakarta is about. As I noted on the Velocity list, 4 years ago I discovered Velocity after identifying Jakarta as a cool Java project resource and then browsing through every project looking for useful libraries. We should encourage that. Yep. I need to post on Idea #3: Jakarta as Java federation at some point :) Which mainly means having links and decriptions to other Java projects at Apache and making [EMAIL PROTECTED] more of a discussion list than Jakarta business list. * I'm skeptical about the common build and web site part of your plan. Agreed that technical issues may cloud this one. Having common structure allows for people to work on each component more easily; but more importantly it forces us into a single community. It also stops components becoming component trees. ie) I'll be pushing for velocity-tools to be a separate component from velocity. Guess an SVN reorg will probably be in the works at some point :) One part of common build is that each component produces only 1 deliverable. Not sure if that's worked perfectly in Commons, a few components have a couple of jars, though 1 is always the most important (much like velocity/velocity-tools). Producing 1 deliverable stops subcomponentizing. Seems like an awful lot of reorg work for little purpose. Many sites have a maven site build. Who is going to integrate all of the projects so that the individually desired features appear on each site. Same for building. Velocity has a mildly customized build script that compiles differently under JDK 1.3 and JDK 1.4/5. If we go to a master web site and build this will make it too difficult to introduce changes to the proces and will stifle innovation. Better to keep this at the subproject level. (Note: *goto jail, do not pass go* s/subproject/component/ No more subprojects :) Jakarta-wide style guidelines with common fonts, colors, logos would be a great idea though). Good point. Common general lf binds us together more. * Also, I'm against changing the project names. Velocity (for example) is a recognizable brand name. Calling it Jakarta Template Language or something similar would be foolish. It'd be Jakarta Velocity; but it might fall in the TemplateLanguage group. I think we'll need groupings for sanity's sake, but we have to avoid them gaining character. They're just vague tags and not actual subprojects. * On a positive note, establishing a standard template for web site format and build would speed up the introduction of new subprojects. We could migrate the common subprojects to a standard, and encourage new subprojects to use it. But if a group wants to modify this template for one piece of it - why not? (as long as they keep some common Jakarta fonts, colors, etc). Right. Individual character is important. Same with the build; as long as it's largely the same, individual bits to handle individual issues are fine. We just need to have the norm be to be similar. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
Almost completely +1. One thing first : http://java.apache.org, redirects to archive.apache.org, while I still know people that are think java stuff stuff on apache.org is happening there, so maybe a redirect to a more friendly page could take place there ? (though this could be something for infrastructure/board). Henri Yandell wrote: * Improved Committer-PMC process. Chair's responsibility (I've failed at this so far) is to turn around the new committer process. A new committer of 6 months is effectively voted against going to the PMC, not for. Might not be able to make it exactly that way, but the idea being that joining the PMC is the exception, not the norm. Personally I'd like to see committership be removed if people repeatedly are not allowed onto the PMC. Just to make sure I get what you are saying : If you become a committer on jakarta, a vote will be helt automatically after 6 months (initiated by you/the Chair?), but not to accept the committer, but to not accept the committer becoming a member of the PMC ? Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
On Tue, 10 Jan 2006, Martin van den Bemt wrote: Almost completely +1. One thing first : http://java.apache.org, redirects to archive.apache.org, while I still know people that are think java stuff stuff on apache.org is happening there, so maybe a redirect to a more friendly page could take place there ? (though this could be something for infrastructure/board). Hmm. I'll mention it, there might be legal issues in active use of the name. Henri Yandell wrote: * Improved Committer-PMC process. Chair's responsibility (I've failed at this so far) is to turn around the new committer process. A new committer of 6 months is effectively voted against going to the PMC, not for. Might not be able to make it exactly that way, but the idea being that joining the PMC is the exception, not the norm. Personally I'd like to see committership be removed if people repeatedly are not allowed onto the PMC. Just to make sure I get what you are saying : If you become a committer on jakarta, a vote will be helt automatically after 6 months (initiated by you/the Chair?), but not to accept the committer, but to not accept the committer becoming a member of the PMC ? That's effectively the level I'd like to take it to. Really drive home the 'everyone should be on the PMC' meme. It's not much different than what could exist today; ie) the chair calling votes based on time since committership; so it's not a biggy - the important part is making a smooth pipeline to the PMC. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
On 1/10/06, Henri Yandell [EMAIL PROTECTED] wrote: As a second email in the Notice of intent series; here's what I think being a Jakarta component will be like in the future. * Jakarta is a collection of components. Hopefully all sitting at the same level. ie) a big bag of things. * Groups exist. These are categorically not subprojects, but a way to allow for slicing of the website etc. Some groups may have their own mail list; thus the importance of making sure they don't become subprojects. An important rule will probably be that they must do votes on the main list. I prefer the term groupings (which, interestingly, you switch to below ;) over groups. I also think we should allow the component:grouping relationship to be 1:N, since not all components will fit tidily into a single grouping. As a corollary, I don't believe groupings should have their own mailing lists. Hopefully we can keep it at a point where the groups are really just there to refine the flow of mail, not to separate it. HttpComponents is an example of this (though not a good one as most of its components came from HttpClient). WebComponents (formerly hoped to be known as Silk) is another example. Commons would be groupalized out. Hopefully. Groupings are not vague names - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The idea with that being that boring grouping names are intentionally dull, no subcommunity identification. * No svn authentication beyond being in the jakarta group. Velocity coders have rw access to POI. * Improved Committer-PMC process. Chair's responsibility (I've failed at this so far) is to turn around the new committer process. A new committer of 6 months is effectively voted against going to the PMC, not for. Might not be able to make it exactly that way, but the idea being that joining the PMC is the exception, not the norm. Personally I'd like to see committership be removed if people repeatedly are not allowed onto the PMC. Well, except that the process is that the PMC has to vote in a new committer to the PMC and then notify the board of that vote. I'm definitely not in favour of magic notifications to the board when the six months are up, without an associated vote. * Application of Commons thinking. Not entirely sure on this one as I think we've overcomplicated things in Commons a bit; but things like a common build system, common site system etc. * Sandbox becomes a Jakarta resource, not a Commons resource. Much of the same rules as it has currently. Probably a separate mailing list. A separate mailing list for the sandbox would be a double-edged sword.Yes, it would keep the noise out of other mailing lists, but it also, at least, partially condemns sandbox components to death, by limiting their exposure much more than now. And if everyone has to subscribe to the sandbox list anyway, to know what's happening, then a separate list is of limited utility. -- Martin Cooper - Shout, scream, yell :) Hen On Mon, 12 Dec 2005, Henri Yandell wrote: dum de dum de dum. Just to be public so that it doesn't look like I'm sneaking around trying to manipulate things. -- I'm starting to open the question of TLP on many of the Jakarta dev mailing lists. It's with a general plan where we would see another half a dozen subprojects move to TLP and then really leave Commons as the main entity inside Jakarta along with some commons-like components that are currently subprojects. I've been talking unofficially with lots of people at ApacheCon, so I've had a fair bit of feedback on various bits. The important part is that the loose plan above finds a way to coalesce the Jakarta community into a much tighter, more TLP e like project. I've talked with a couple of board members to feel out things would be. One question being, is it a problem if we're pushing a TLP with just a few committers. The answer I had was that Excalibur is the example TLP, it's rather dormant and it's not a problem. I was also advised to be a bit more active in pushing forward. I think this makes sense, a lot of our cross-community activity is gone because people with high activity tend to move to TLP, so we need a bit more drive to get things done. Thus the change of tack that I'll be trying to pull off without getting hung :) Please discuss, argue, wibble; but what I'm looking for are active ways forward instead of maintaining the status quo. I don't think the status quo is good for Jakarta as an entity, it puts strain on our oversight because the number of subprojects stretches the chair's and community in general's ability to keeps things covered. *denies the blindfold and stands against the wall waiting* Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
On Tue, 2006-01-10 at 10:20 -0800, Martin Cooper wrote: On 1/10/06, Henri Yandell [EMAIL PROTECTED] wrote: As a second email in the Notice of intent series; here's what I think being a Jakarta component will be like in the future. * Jakarta is a collection of components. Hopefully all sitting at the same level. ie) a big bag of things. * Groups exist. These are categorically not subprojects, but a way to allow for slicing of the website etc. Some groups may have their own mail list; thus the importance of making sure they don't become subprojects. An important rule will probably be that they must do votes on the main list. I prefer the term groupings (which, interestingly, you switch to below ;) over groups. +1 gave up groups (topological or even finite simple) when i left uni ;) I also think we should allow the component:grouping relationship to be 1:N, since not all components will fit tidily into a single grouping. As a corollary, I don't believe groupings should have their own mailing lists. not sure i like the idea of fuzzy groupings with 1-N components need to be mapped 1-1 to dev mailing lists but 1-N would work fine on user lists. might be possible to factor 1-1 dev lists (for traffic purposes) whilst retaining fuzzy users lists. Hopefully we can keep it at a point where the groups are really just there to refine the flow of mail, not to separate it. HttpComponents is an example of this (though not a good one as most of its components came from HttpClient). WebComponents (formerly hoped to be known as Silk) is another example. Commons would be groupalized out. Hopefully. Groupings are not vague names - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The idea with that being that boring grouping names are intentionally dull, no subcommunity identification. * No svn authentication beyond being in the jakarta group. Velocity coders have rw access to POI. * Improved Committer-PMC process. Chair's responsibility (I've failed at this so far) is to turn around the new committer process. A new committer of 6 months is effectively voted against going to the PMC, not for. Might not be able to make it exactly that way, but the idea being that joining the PMC is the exception, not the norm. Personally I'd like to see committership be removed if people repeatedly are not allowed onto the PMC. Well, except that the process is that the PMC has to vote in a new committer to the PMC and then notify the board of that vote. I'm definitely not in favour of magic notifications to the board when the six months are up, without an associated vote. i don't like the idea of magic notifications (to the board) but something needs to be done: ATM we're dysfunctional. just take a look at the nominations per nominator over the last year or two: nomination hasn't become ingrained in the culture. ATM we're slipping up but maybe statistics and reminders may be better for the moment than automatic nomination... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
On Tue, 10 Jan 2006, robert burrell donkin wrote: On Tue, 2006-01-10 at 10:20 -0800, Martin Cooper wrote: On 1/10/06, Henri Yandell [EMAIL PROTECTED] wrote: * Groups exist. These are categorically not subprojects, but a way to allow for slicing of the website etc. Some groups may have their own mail list; thus the importance of making sure they don't become subprojects. An important rule will probably be that they must do votes on the main list. I prefer the term groupings (which, interestingly, you switch to below ;) over groups. +1 +1. You're right, groupings is much better. * Improved Committer-PMC process. Chair's responsibility (I've failed at this so far) is to turn around the new committer process. A new committer of 6 months is effectively voted against going to the PMC, not for. Might not be able to make it exactly that way, but the idea being that joining the PMC is the exception, not the norm. Personally I'd like to see committership be removed if people repeatedly are not allowed onto the PMC. Well, except that the process is that the PMC has to vote in a new committer to the PMC and then notify the board of that vote. I'm definitely not in favour of magic notifications to the board when the six months are up, without an associated vote. i don't like the idea of magic notifications (to the board) but something needs to be done: ATM we're dysfunctional. just take a look at the nominations per nominator over the last year or two: nomination hasn't become ingrained in the culture. ATM we're slipping up but maybe statistics and reminders may be better for the moment than automatic nomination... +1 to reminder. The board list has a reminder to chairs to submit their report. We should have a similar thing, a reminder to [EMAIL PROTECTED] that the following people should be considered for the pmc. Easiest method is to have something that compares svn structure for jakarta (easier when we have only one auth) and the committee-info.txt file. Doesn't catch new committers who are not in svn yet, but a good 80/20. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
