used Jmeter for web testing?
Please respond if you have used this tool or you know how to use it.
Thanks,
Jim.
-Original Message-
From: robert burrell donkin
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 14, 2004 2:57 PM
To: Jakarta General List
Subject: Re: Apache CVS (was Re: Lessons
we're moving to subversion and there have been quite
a few discussions
about the best ways of laying our repositories
recently. if you can use
subversion, seriously consider using it. the way our
subversion
repository is laid out is a little different.
- robert
Hmm... I have been
-Original Message-
From: Richard Bair [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 14, 2004 5:37 PM
To: Jakarta General List
Subject: Re: Apache CVS (was Re: Lessons Learned)
we're moving to subversion and there have been quite a few
discussions
about the best ways of laying
On 13 Dec 2004, at 01:04, Felipe Leme wrote:
On Sun, 2004-12-12 at 21:15, robert burrell donkin wrote:
though committing a few risky patches in the hope of recruiting a new
committer might seem like a good plan, there are definite drawbacks.
I agree. I didn't mean that all patches, but they should
On 13 Dec 2004, at 22:20, Richard Bair wrote:
Thanks everyone for your insight!
Related to this, I have a question regarding the
organizational structure of CVS. I noticed that
cvs.apache.org has, predictably, a different package
for all of the top-level projects, and even
sub-projects (although
CVS (was Re: Lessons Learned)
On 13 Dec 2004, at 22:20, Richard Bair wrote:
Thanks everyone for your insight!
Related to this, I have a question regarding the
organizational structure of CVS. I noticed that
cvs.apache.org has, predictably, a different package
for all of the top-level projects
Thanks everyone for your insight!
Related to this, I have a question regarding the
organizational structure of CVS. I noticed that
cvs.apache.org has, predictably, a different package
for all of the top-level projects, and even
sub-projects (although all of the commons-components
are considered
Unless, for example, you do this intentionally ;)
Oliver
On Sun, 12 Dec 2004 15:30:10 -0200, Felipe Leme
[EMAIL PROTECTED] wrote:
I would add a note to Danny's comment: treat contributors as your
primary users.
I have seem many projects (inside and outside ASF) where people submit
patches
On 12 Dec 2004, at 17:30, Felipe Leme wrote:
I would add a note to Danny's comment: treat contributors as your
primary users.
I have seem many projects (inside and outside ASF) where people submit
patches and the patches are just ignored, without even an explanation
why it was not accepted. I know
On Sun, 2004-12-12 at 21:15, robert burrell donkin wrote:
though committing a few risky patches in the hope of recruiting a new
committer might seem like a good plan, there are definite drawbacks.
I agree. I didn't mean that all patches, but they should at least be
'acknowledged'. Even a
I would add a note to Danny's comment: treat contributors as your
primary users.
I have seem many projects (inside and outside ASF) where people submit
patches and the patches are just ignored, without even an explanation
why it was not accepted. I know that applying a patch is not that simple
in
robert burrell donkin wrote:
beware too many organizational layers. flat is best. having a single
sub-project with many releasables artifacts sharing the same community
space (mailing lists, committer lists, voting eligability and so on) has
proved more successful (see jakarta commons) than a
On 10 Dec 2004, at 09:28, Danny Angus wrote:
If you were starting all over today, what things would you have
done differently? What are the blind alleys?
snip
Keep it simple. Keep it public. Have one official communication
channel for
decision making, we use well publicised mailinglists for a
Richard,
Hi.
I was wondering; what are the lessons learned?
Everything you see is a lesson learned, what you see in practice is our
best, but still admittedly flawed, practice.
If you were starting all over today, what things would you have
done differently? What are the blind alleys?
I'm
Thanks everybody for their input.
Jakarta is a meritocracy, I believe that that is why
it works. But I think
the real lesson for you is, don't ask *us*, have a
look at what we do but
ask your own community to make these choices.
Will do!
Thanks
Richard
it comes to hosting open
source projects and an open source community. I was
wondering; what are the lessons learned? If you were
starting all over today, what things would you have
done differently? What are the blind alleys?
Also, I have been researching and designing the build
process
16 matches
Mail list logo