On 15 Dec 2004, at 02:27, Tim O'Brien wrote:
I believe the plan is to have a directory per subproject. Below that,
structure will depend on what an individual subproject needs. But,
there are some tricky questions to answer especially in subprojects
with
multiple "artifacts". Take jakarta commo
trunk, tags, and branches will go.
Tim
> -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 subversi
Richard Bair wrote:
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
> 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
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
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 al
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 al
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
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 co
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 co
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 co
Great post, completely agreed!
This may sound arrogant, but sometimes there are patches that simply
seem hopeless. One strategy not to offend anyone while rejecting the
patch is to intentionally ignore it.
Oliver
On Sun, 12 Dec 2004 23:15:20 +, robert burrell donkin
<[EMAIL PROTECTED]> wrot
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
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
> p
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
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?
Keep it simple. Keep it public. Have one official communication
channel for
decision making, we use well publicised mailinglists for a reason,
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
_
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 bli
;all are the experts when 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 t
19 matches
Mail list logo
