Re: testing.apache.org, take 2
But testing ~is~ fun when you know from experience how much time it is saving you. (sort of...as fun as programming can be right? who said we weren't robots ? ;) ) On 7/11/06, Han ChuanBing <[EMAIL PROTECTED]> wrote: It's very hard to have fun with testing, especially when a job shall be repeated again and again. Maybe a robot can do that when there is a standard. On 7/11/06, Roland Weber <[EMAIL PROTECTED]> wrote: > > Jesse Kuhnert wrote: > > "The Rack" conjures up images having nothing to do with torture for me. > > (probably because I'm such a filthy animal) ;) > > I guess software quality would be much higher > if more people had *fun* with testing... ;-) > > cheers, > Roland > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: testing.apache.org, take 2
It's very hard to have fun with testing, especially when a job shall be repeated again and again. Maybe a robot can do that when there is a standard. On 7/11/06, Roland Weber <[EMAIL PROTECTED]> wrote: Jesse Kuhnert wrote: > "The Rack" conjures up images having nothing to do with torture for me. > (probably because I'm such a filthy animal) ;) I guess software quality would be much higher if more people had *fun* with testing... ;-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Jesse Kuhnert wrote: > "The Rack" conjures up images having nothing to do with torture for me. > (probably because I'm such a filthy animal) ;) I guess software quality would be much higher if more people had *fun* with testing... ;-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
On Tue, 27 Jun 2006, Henri Yandell wrote: There's a security related one in front of the board this month, which has much of the same issues as the testing one so (I reckon) that'll be just as educational as pushing the current testing thoughts to the board. This resolution was passed, but it ended up just being the promotion of the XML Security subproject to TLP (as Santuario). XML's slowly breaking up as a TLP, so this was a natural continuation of that. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
"The Rack" conjures up images having nothing to do with torture for me. (probably because I'm such a filthy animal) ;) On 7/10/06, Roland Weber <[EMAIL PROTECTED]> wrote: Hi folks, what has happened to this thread? Ever since Henri wrote that it's heading in the right direction, it seems to be dead. Bad beer chitchat hangover? Summer break? Everyone busy watching soccer? Or were my last suggestions so far off that they don't even deserve a response? Just to get discussion starting again, here is yet another alternative name suggestion: "The Rack" in reminiscence of a 70s british TV series :-) http://www.personal.u-net.com/~carnfort/Professionals/b02.htm cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: testing.apache.org, take 2
Hi folks, what has happened to this thread? Ever since Henri wrote that it's heading in the right direction, it seems to be dead. Bad beer chitchat hangover? Summer break? Everyone busy watching soccer? Or were my last suggestions so far off that they don't even deserve a response? Just to get discussion starting again, here is yet another alternative name suggestion: "The Rack" in reminiscence of a 70s british TV series :-) http://www.personal.u-net.com/~carnfort/Professionals/b02.htm cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Very good thread that I think is heading in the right direction. My thinking is that it should continue for the next month and be put in front of the board then if it has reached a good state. There's a security related one in front of the board this month, which has much of the same issues as the testing one so (I reckon) that'll be just as educational as pushing the current testing thoughts to the board. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Hi all, Felipe Leme wrote: > 1.What should it be named ? > 2.What exactly do these 2 projects have in common so they can be > grouped together? > 3.Could the TLP accept more projects? What's the criteria? I suggest we add "runtime testing" to the list of criteria. I guess it's one of those implicit assumptions we've been making, but it really should be pointed out. It reduces the scope by eliminating projects or products like: Gump - build time testing Clover - requires static code analysis to determine test coverage Quality Assurance stuff - something that runs statistics on issues opened or closed resulting from manually executing test cases Those are examples for things "related to testing" that are probably not meant to be in the scope of the currently discussed new project. If I am not mistaken, both Cactus and JMeter are executing test cases at runtime, collecting data without instrumentation of byte code or JVM plugins. By restricting the scope to this kind of testing stuff, we should be able to alleviate some concerns about over-broadness. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Hi Felipe, I fully agree with you. > So, let's say we decide to promote Cactus+JMeter to a TLP > of their own, but not the broad "testing.apache.org"; I have 3 > questions: > > 1.What should it be named ? > 2.What exactly do these 2 projects have in common so they can be > grouped together? > 3.Could the TLP accept more projects? What's the criteria? > > Here are my preliminary answers: > > 2.This is the crucial point and ca be the guide for 1 and 3. Consider > the project originated from Jakarta, whose roots come from the Java in > the server side, we could work on something related to "Java EE > Testing" or "Server-side Java Testing". Java + (focus on) server-side should also allow for the testing related artifacts from Struts and Tomcat mentioned as candidates: http://marc.theaimsgroup.com/?l=jakarta-general&m=115047715227445&w=2 I'm not sure whether server-side should be tied to J2EE though. Maybe the project description should state that it does not claim exclusiveness within it's scope, just to be sure. After all, it is still an effort to create a home for several related projects, and not an attempt to find a solution for a specific technical problem. > 1.I'm too bad on naming (JCacter? MetrusJ? :-). Scrutiny? Ordeal? > 3.My guess is that once 2 is answered, we would have a criteria for > letting new projects be incorporated to the TLP. > > >> Roy Fielding on 6/22: > > >> A federation is simply an umbrella project with no significant >> responsibilities of its own -- all of its projects report directly >> to the board and simply view the federation as a communal thing. >> I think XML and Jakarta should already fall into that category. >> Starting one is just like starting a project, except that the >> purpose is limited to community/commons like things and not actual >> products. " > > Please forgive my ignorance, but I didn't understand this conclusion: > does it means we could have testing as a 'federation TLP'? Os does the > federation concept would apply to the Cactus+JMeter project? The former, I guess. "no significant responsibilities" means that kind of project should not release code itself, the way I read it. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Hi Phil, On 6/23/06, Phil Steitz <[EMAIL PROTECTED]> wrote: With his permission, I am forwarding an excerpt from a recent post from Roy Fielding, in response to questions about a proposed "Security" TLP originating out of the XML project. The concerns he raises below all pretty much apply directly to Testing. That post pretty much explain the umbrella issue; it would be nice to have it somewhere on Apache's site, so it can be used in other situations. Could be the right approach here is to limit it to Cactus + Jmeter, or even have them each TLP separtately. That was Hen's original idea, but it faded away as these projects didn't feel confident enough to have a TLP of their own (for instance, I'm pretty much the only active Cactus committer right now, and not that active; JMeter is being more active commmitter-wide, but they were not willing to be TLPed alone). OTOH, we had drawn the attention of more people - many of them current Jakarta PMC members, like Rahul, Dion and Yoav - once we pushed the testing TLP, so maybe the JMeter+Cactus TLP could be doable now, although it still requires some decisions/definitions (see below). I think the key is really point 1. above as well as Roy's argument below about not claiming dominion over a topical area. Ok, I agree. So, let's say we decide to promote Cactus+JMeter to a TLP of their own, but not the broad "testing.apache.org"; I have 3 questions: 1.What should it be named ? 2.What exactly do these 2 projects have in common so they can be grouped together? 3.Could the TLP accept more projects? What's the criteria? Here are my preliminary answers: 2.This is the crucial point and ca be the guide for 1 and 3. Consider the project originated from Jakarta, whose roots come from the Java in the server side, we could work on something related to "Java EE Testing" or "Server-side Java Testing". 1.I'm too bad on naming (JCacter? MetrusJ? :-). 3.My guess is that once 2 is answered, we would have a criteria for letting new projects be incorporated to the TLP. Roy Fielding on 6/22: A federation is simply an umbrella project with no significant responsibilities of its own -- all of its projects report directly to the board and simply view the federation as a communal thing. I think XML and Jakarta should already fall into that category. Starting one is just like starting a project, except that the purpose is limited to community/commons like things and not actual products. " Please forgive my ignorance, but I didn't understand this conclusion: does it means we could have testing as a 'federation TLP'? Os does the federation concept would apply to the Cactus+JMeter project? []s, -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Rahul Akolkar wrote: > On 6/20/06, Phil Steitz <[EMAIL PROTECTED]> wrote: >> Rahul Akolkar wrote: >> > On 6/16/06, Felipe Leme <[EMAIL PROTECTED]> wrote: >> > >> >> >> >> I think these statements are a good start for the next meeting's >> >> proposal - could someone write an wiki entry for it (or even update >> >> the current resolution)? I'm traveling until Sunday and my internet >> >> connection is pretty bad here, so it would be hard for me to do it... >> >> >> > >> > >> > Thanks for putting it all together as a summary, I've put the closing >> > statements from that email, verbatim, on a wiki page [1]. Its open to >> > edits (I might make some minor edits myself in a day or two). >> This is good. Here are a few additional things that we might want to >> think about adding, assuming all are OK with these commitments. > > > This (below) is generally in line with my expectations of how things > should work, and aligned to what we've said previously in these > threads, IMO. > > Ideally, there'd be a mechanism to get some feedback, even in your > absence (thanks for volunteering though). > > -Rahul > > >> This >> list is designed to address some of the concerns that have been raised >> in the past about umbrella projects. Obviously, not all may agree with >> the points below, and even with these provisions, the board may not >> approve the Testing proposal. I just thought it would be a good idea to >> get these ideas out for discussion for this and the other >> "umbrella-like" things that we may be splitting Jakarta into. >> >> 1. The PMC members named in the proposal are signing up to provide >> oversight for the *entire project*, not just "subprojects" that they >> participate in. In fact, there are formally no subprojects, just >> products or code bases that are versioned / released separately. I >> would recommend that we avoid the use of the term "project" other than >> for the TLP itself and avoid "subproject" altogether. >> 2. As new components are incorporated, the PMC will grow and will >> always include the (the majority of) active committers working on each >> of the components. Ability to make decisions on behalf of the whole >> project will be considered when granting commit access. >> 3. A necessary condition for adoption of a codebase or creation of a >> new component will be commitment from a minimum of 3 PMC members >> (possibly existing ASF committers, joining with the codebase) agreeing >> to review / apply patches, review commits, serve as RM, etc. for the new >> component. >> 4. If one or more of the components, or the entire project, grows in >> complexity or community size to >> the point where effective oversight / active involvement by the Testing >> PMC on all components is no longer possible, the project will be split >> (just as Jakarta is being split now, per this proposal). Note that this >> is a statement of intent, not an administrative mandate (i.e., the >> somewhat painful, consensus-driven process that we are following now in >> Jakarta is our *intention* to improve and maintain). >> 5. Inactive components, or components without a sufficient number of >> active PMC members, will be regularly archived. >> >> One more personal thing: >> >> I just learned that the board meeting has been postponed until next >> Tuesday. Unfortunately, I will not able to attend that day. Therefore, >> it would be great if one of the other members supporting this proposal >> could step up to attend. >> >> Phil With his permission, I am forwarding an excerpt from a recent post from Roy Fielding, in response to questions about a proposed "Security" TLP originating out of the XML project. The concerns he raises below all pretty much apply directly to Testing. Could be the right approach here is to limit it to Cactus + Jmeter, or even have them each TLP separtately. I think the key is really point 1. above as well as Roy's argument below about not claiming dominion over a topical area. Roy Fielding on 6/22: "When a project "owns" a category, such as security, the participants think that they are responsible for all Apache products in that space. Meanwhile, what they are actually working on is a fairly small project that addresses the specific requirements of a given set of users, such as xml-security. People don't try to make products that are applicable to every possible consumer in a given category, and volunteers cannot oversee projects in which they do not actually participate. What is left is either a single project that rejects all new target audiences or an umbrella project that creates an artificial barrier to oversight. There is no way to broaden the perspective of a project -- people simply don't wake up one day and discover a need to be aware of everyone else's work in similar projects, and most people don't have the bandwidth to do so anyway. That is why each project has to be self-governed. When someone else comes along and says an obvious thing like "XML
Re: testing.apache.org, take 2
On 6/20/06, Phil Steitz <[EMAIL PROTECTED]> wrote: Rahul Akolkar wrote: > On 6/16/06, Felipe Leme <[EMAIL PROTECTED]> wrote: > >> >> I think these statements are a good start for the next meeting's >> proposal - could someone write an wiki entry for it (or even update >> the current resolution)? I'm traveling until Sunday and my internet >> connection is pretty bad here, so it would be hard for me to do it... >> > > > Thanks for putting it all together as a summary, I've put the closing > statements from that email, verbatim, on a wiki page [1]. Its open to > edits (I might make some minor edits myself in a day or two). This is good. Here are a few additional things that we might want to think about adding, assuming all are OK with these commitments. This (below) is generally in line with my expectations of how things should work, and aligned to what we've said previously in these threads, IMO. Ideally, there'd be a mechanism to get some feedback, even in your absence (thanks for volunteering though). -Rahul This list is designed to address some of the concerns that have been raised in the past about umbrella projects. Obviously, not all may agree with the points below, and even with these provisions, the board may not approve the Testing proposal. I just thought it would be a good idea to get these ideas out for discussion for this and the other "umbrella-like" things that we may be splitting Jakarta into. 1. The PMC members named in the proposal are signing up to provide oversight for the *entire project*, not just "subprojects" that they participate in. In fact, there are formally no subprojects, just products or code bases that are versioned / released separately. I would recommend that we avoid the use of the term "project" other than for the TLP itself and avoid "subproject" altogether. 2. As new components are incorporated, the PMC will grow and will always include the (the majority of) active committers working on each of the components. Ability to make decisions on behalf of the whole project will be considered when granting commit access. 3. A necessary condition for adoption of a codebase or creation of a new component will be commitment from a minimum of 3 PMC members (possibly existing ASF committers, joining with the codebase) agreeing to review / apply patches, review commits, serve as RM, etc. for the new component. 4. If one or more of the components, or the entire project, grows in complexity or community size to the point where effective oversight / active involvement by the Testing PMC on all components is no longer possible, the project will be split (just as Jakarta is being split now, per this proposal). Note that this is a statement of intent, not an administrative mandate (i.e., the somewhat painful, consensus-driven process that we are following now in Jakarta is our *intention* to improve and maintain). 5. Inactive components, or components without a sufficient number of active PMC members, will be regularly archived. One more personal thing: I just learned that the board meeting has been postponed until next Tuesday. Unfortunately, I will not able to attend that day. Therefore, it would be great if one of the other members supporting this proposal could step up to attend. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Rahul Akolkar wrote: > On 6/16/06, Felipe Leme <[EMAIL PROTECTED]> wrote: > >> >> I think these statements are a good start for the next meeting's >> proposal - could someone write an wiki entry for it (or even update >> the current resolution)? I'm traveling until Sunday and my internet >> connection is pretty bad here, so it would be hard for me to do it... >> > > > Thanks for putting it all together as a summary, I've put the closing > statements from that email, verbatim, on a wiki page [1]. Its open to > edits (I might make some minor edits myself in a day or two). This is good. Here are a few additional things that we might want to think about adding, assuming all are OK with these commitments. This list is designed to address some of the concerns that have been raised in the past about umbrella projects. Obviously, not all may agree with the points below, and even with these provisions, the board may not approve the Testing proposal. I just thought it would be a good idea to get these ideas out for discussion for this and the other "umbrella-like" things that we may be splitting Jakarta into. 1. The PMC members named in the proposal are signing up to provide oversight for the *entire project*, not just "subprojects" that they participate in. In fact, there are formally no subprojects, just products or code bases that are versioned / released separately. I would recommend that we avoid the use of the term "project" other than for the TLP itself and avoid "subproject" altogether. 2. As new components are incorporated, the PMC will grow and will always include the (the majority of) active committers working on each of the components. Ability to make decisions on behalf of the whole project will be considered when granting commit access. 3. A necessary condition for adoption of a codebase or creation of a new component will be commitment from a minimum of 3 PMC members (possibly existing ASF committers, joining with the codebase) agreeing to review / apply patches, review commits, serve as RM, etc. for the new component. 4. If one or more of the components, or the entire project, grows in complexity or community size to the point where effective oversight / active involvement by the Testing PMC on all components is no longer possible, the project will be split (just as Jakarta is being split now, per this proposal). Note that this is a statement of intent, not an administrative mandate (i.e., the somewhat painful, consensus-driven process that we are following now in Jakarta is our *intention* to improve and maintain). 5. Inactive components, or components without a sufficient number of active PMC members, will be regularly archived. One more personal thing: I just learned that the board meeting has been postponed until next Tuesday. Unfortunately, I will not able to attend that day. Therefore, it would be great if one of the other members supporting this proposal could step up to attend. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
On 6/16/06, Felipe Leme <[EMAIL PROTECTED]> wrote: I think these statements are a good start for the next meeting's proposal - could someone write an wiki entry for it (or even update the current resolution)? I'm traveling until Sunday and my internet connection is pretty bad here, so it would be hard for me to do it... Thanks for putting it all together as a summary, I've put the closing statements from that email, verbatim, on a wiki page [1]. Its open to edits (I might make some minor edits myself in a day or two). -Rahul [1] http://wiki.apache.org/jakarta/TLPCactusAndJMeter/Notes []s, -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
testing.apache.org, take 2
Hi all, Sorry for being quiet so far regarding this issue, but I've been too busy with other real-life subjects (besides, it's World Cup time :-). Anyway, I've read all messages and will try to write a 'condensed' reply of all pertinent issues, plus a couple of statements summarizing them. As such, it's going to be a long email - so, if you don't have the patience to read all replies (I wouldn't :-), jump straight to the end... On Jun 6, 2006, at 6:13 PM, Rahul Akolkar wrote: Yup, there clearly is developer/community interest towards the formation of this project. I second Rahul's comment here. In fact, the proposal started as an effort from Hen to emancipate some projects (Cactus and JMeter) out of Jakarta, but there are many other projects interested to join the new TLP (I will talk more about those projects later). Plus, there is a chance to rejuvenate some existing projects by sheer proximity to newer projects with active developers (amongst other things). This is another good point: one motivation for the TLP is to bring momentum back to some dormant projects (like Cactus). I'm aware this motivation could be dangerous (we could, for instance, end up with a dormant TLP, which is worse than a dormant sub-project), but I'm still confident it's worth a try. Per the umbrella concern, the question then becomes what -- if any -- are the mitigating factors that can address such a concern with regards to this proposal. Ok, that makes sense: such mitigating factors should be on our proposal for the next meeting (I will bring them back after the replies). On Jun 6, 2006, at 9:47 PM, Henri Yandell wrote: It's more in our court to come up with something to convince them I think. Ok, let's try to come out with concrete arguments for the next meeting. Mostly I think we need to detail the cross-ASF interest in the idea. Otherwise Jakarta Test Ok again, let's do that. So far, I can list the following: - Struts developed some testing artifacts also used by MyFaces - WebWork - which has 'merged' into Struts - seems to have some testing stuff which could be migrated to the TLP - Cactus is (I believed) used by other JavaEE related projects (like Geromino and Struts) - we (Rahul and I) have been contacted in private by committers of other ASF projects (like Tomcat and Struts) willing to donate some code to the new TLP - as mentioned in previous messages, there are many other examples of testing artifacts spread across ASF projects that could be migrated into the new TLP. Of course, each case should be analyzed in particular, as not all of then might be suitable for the TLP, but the point is that we have a 'market' for the TLP. On Jun 9, 2006, at 2:50 AM, Phil Steitz wrote: I would also like to understand exactly what the problem is I think the problem is the fear that the TLP, as an umbrella project, grows up in an unorganized way and becomes more of a problem than a solution. and what mitigating steps may be possible. One such step is to have well defined rules on how an existing project would be accepted in the TLP. For instance, the proponent should 'prove' that the new project would aggregate value to the TLP, either technically and/or by bringing 'development momentum'. Another step (related with the previous one) is to define the incubation/sandbox mechanism for such new projects in a way a little bit more rigid than the regular incubation process. In particular, I would very much appreciate a definition of "umbrella" that allows Geronimo, Logging, Jakarta Commons, DB, XML, Web Services and Struts, but somehow disallows Testing. As others have already pointed out (sorry again for the delay on the reply :-), that definition is not a consensus. Anyway, I think Geronimo and Struts could be risked off the umbrella moniker, as they are focused in a concrete product and not on a generic concept (like the others). Besides, Jakarta Commons - which is the most 'problematic' umbrella, as it's very broad - is not an TLP, but a Jakarta sub-project (well, that's another issue...). On Jun 9, 2006, at 8:55 AM, Jesse Kuhnert wrote: It makes sense that people want to be careful about a tl subdomain. Some of the projects you mentioned are fairly staple diets to a good majority of development projects. (ie struts/logging/xml/commons/etc) . Yes, that's sort of what I meant previously (sorry for the redundancy). Maybe we (ASF) need a formal definition of what makes a TLP: for instance, it could be either a major project with some minor sub-projects (like Struts, Tomcat, Geronimo, Maven, Tapestry, etc..) or the (in) famous 'umbrella' (like Jakarta, DB, XML, Logging, Commons and hopefully Testing). In other words, we would be treating the umbrellas as 'first-class TLPs', and not some sort of 'failed experiments' (please note that I'm not affirming the aforementioned projects are failures, much the opposite. It's just a lack of a better expression :-( What would go into testing.apache.org? I'm all for it as testin
