On 4/01/2003 2:34 AM, "Jordi Salvat i Alabart" <[EMAIL PROTECTED]> wrote:
> Dear co-contributors, > > I've been thinking about some non-technical JMeter issues which I'd like > to share with you. It's mostly issues that have been raised into this > list during the recent weeks and have been only partially addressed. I'm > just exposing them here because I think they need further discussion. > > 1/ Committers > > We all agree that we need to keep the ball rolling (in my case, because > I use JMeter for work and need it getting better as fast as possible, > others will have their own reasons). My (our?) current strategy is to > get as much people on-board as possible: if they don't touch at CVS, > makes no harm, if they touch, it makes progress. Of course this was > absolutely necessary at the recent stage of the project, where it was > getting stalled, but can become a problem in the future. Would be nice > to discuss where we want go to in this matter. For example, I would > propose a consensus policy requiring any committer to relinquish his > rights before unsubscribing from the dev mailing list -- if we ever > suspect someone has "disappeared" from the project, we can ping him on > the list. If we do this, we will know how many active committers there > are, and we can react if it gets below a certain threshold. I agree with the comments already posted that existing apache guidelines cover this situation - the last thing we need is the distraction of implementing a bunch of jmeter specific operational guidelines (let's work on jmeter instead). > > 2/ Contributions > > We want to encourage the people who use JMeter to contribute. I believe > the best way to do this is to make things easy for them. In my opinion, > there's some technical aspects of JMeter which place a too high > threshold on this. The relationship between GUI and test elements and > this Avalon configuration stuff were the most important for me. Poor > JavaDoc documentation is another. Absence of nightly builds is probably > the worse. Even sloppy indenting contributes to the difficulties. Is > there any non-technical issues we should address on this matter? Conor MacNeill has signified his willingness to address the Gump/nightly build issue - this is great. Checkstyle and coding standards has been mentioned by a couple of people. Again, I think we are best off adopting pre-existing rules if at all possible. One possible option is to simply adopt the Turbine coding standards: http://jakarta.apache.org/turbine/common/code-standards.html Has anyone looked at the possibility of using Maven (http://jakarta.apache.org/turbine/maven/) to build jmeter? This is currently being used by all of the Turbine projects (well it would, it is a Turbine project itself) as well as many of the jakarta commons components. This might provide a fairly nice way to integrate checkstyle and potentially other useful features to the jmeter build process (checkstyle reports are integrated into the project site). > > 3/ Long-term development plan > > We lack a long-term development plan. JMeter is still far from being a > mature product, yet its development is mainly driven by bug-fixing and > small functional enhancements. At the very least, we need to agree on a > loose high-level end-user requirement list [I think I already have a > document of this kind somewhere -- the one I used to select JMeter among > other tools quite a few months ago]. I too am maintaining a list of enhancements I would like to see in jmeter. I think the wiki (http://nagoya.apache.org/wiki/apachewiki.cgi?JMeterProjectPages) may provide a useful place for us to all combine our lists and to attempt to determine which bits to work on for the next and future releases. Inline voting can be used to help work out the priorities, etc. Wiki pages are unstructured by design so it may take a little effort to work out the best way of pulling this stuff together, but I think it may be a lot easier to manage in the wiki than in the mailing list (and you can still drop a note to the mailing list if you make a significant update on the wiki that you want to bring to everyone's attention). > > Opinions? > > Salut, > > Jordi. Cheers, Scott -- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au .Mac Chat/AIM: seade at mac dot com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
