Jordi Salvat i Alabart wrote:
Dear co-contributors,You should propose people when they demonstrate continued contribution to the project. That contribution can take many forms (code, testing, documentation, web site development, etc). I don't think you should propose people without some sort of track record. IMHO, JMeter is now revitalised so I don't think the recent actions to add a large batch of committers in one fell swoop needs to be repeated.
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.Yes, but this is part of what it means to work on an Apache project. You must reach consensus (or lazy consensus). This is why you should be confident in the people you propose as committers. You are giving them the right to vote on the project's future direction. There are mechanisms to overcome blockages, but they are rarely invoked and usually indicate a more serious problem in the project.
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.There are some conventions at Apache for this situation. See
http://httpd.apache.org/dev/guidelines.html
Note that in most projects, committers often go "quiet" for extended periods without being declared "inactive". It depends on how the project wishes to maintain this but most don't go tot he effort of roll calls, etc. It is usually obvious who is active by their response to VOTE actions.
2/ ContributionsI can help with the Gump side of things and getting nightly builds going. For the style and javadoc issues, I'd suggest the use of checkstyle to identify and then correct issues. You can start with a loose set to start with and then tighten up as time passes.
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?
3/ Long-term development plan
Long term plans are a good idea :-). Conor -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
