At 07:15 27/2/01 -0500, Ted Husted wrote:
>In my own mind, I visualize the library as
>
>(1) A catalog of reusable components available from any and all Jakarta
>subprojects, including user contributions.
>
>(2) A place where people can create and maintain production-quality
>packages designed f
Peter Donald wrote:
> So what I would be interested in doing would be to ask the PMC to allow us
> to create a new CVS (jakarta-avalon-catalog or something). This would be
> the place to burn through all the ideas and see where it leads. At the
> point where the project could stand on it's own two
On Tue, 27 Feb 2001, Peter Donald wrote:
> At 12:23 26/2/01 -0500, Ted Husted wrote:
> >(0) rationale
> >
> >Apache-Java and Jakarta originally hosted product-based subprojects,
> >consisting of one major deliverable. The Java language however is
> >package-based, and most of these products ha
Peter Donald wrote:
>
> So what I would be interested in doing would be to ask the PMC
> to allow us to create a new CVS (jakarta-avalon-catalog or
> something).
Why not jakarta-avalon-dbpool?
- Sam Ruby
Peter Donald wrote:
>
> At 08:04 26/2/01 -0800, [EMAIL PROTECTED] wrote:
> >The only (detail) I'm still woried about in the library project is the
> >fact that the goal is almost identical with what I think to be the goal
> >for Avalon. Maybe it would be a better idea to make avalon work and joi
At 08:04 26/2/01 -0800, [EMAIL PROTECTED] wrote:
>The only (detail) I'm still woried about in the library project is the
>fact that the goal is almost identical with what I think to be the goal
>for Avalon. Maybe it would be a better idea to make avalon work and join
>it instead of creating a new
At 12:23 26/2/01 -0500, Ted Husted wrote:
>(0) rationale
>
>Apache-Java and Jakarta originally hosted product-based subprojects,
>consisting of one major deliverable. The Java language however is
>package-based, and most of these products have many useful utilities.
>Some products are beginning
> My understanding of Costins view of the *purpose* of the library is to
> have a place where components that are shared between Jakarta projects
> can be stored, shared, developed, etc. From what I gather, his vision is
> that it would be a place where sharable but not necessarily
> productizable
> > 1) A central resource 'repository', as envisioned by Costin
> >(and others).
> >
> > 2) A central component 'Catalog', as envisioned by myself
> >(and others).
>
> Perhaps I'm dense, but I really don't see a sharp dividing line between the
> two.
>
> Is the point of #1 to include thi
One comment:
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> Sam Ruby wrote:
> >
> > Ted Husted wrote:
> > >
> > > I've never actually seen a subproject proposal,
> and so only know
> > > what is written in the guidelines ;-)
> >
> > I'd say that the essential elements are name,
> scope, rationalle
> Quite honestly, I don't know 100% what Costin seeks. I thought my #1
:-)
Mea culpa, I should stick with writing java, it's easier than english :-)
> What I *believe* is that what Costin seeks is different from what I
> seek, simply from the direction the result is approached, and with the
Sam Ruby wrote:
>
> Ted Husted wrote:
> >
> > I've never actually seen a subproject proposal, and so only know
> > what is written in the guidelines ;-)
>
> I'd say that the essential elements are name, scope, rationalle, and inital
> list of committers.
>
> Is the initial scope intended to be
Ted Husted wrote:
>
> I've never actually seen a subproject proposal, and so only know
> what is written in the guidelines ;-)
I'd say that the essential elements are name, scope, rationalle, and inital
list of committers.
Is the initial scope intended to be simply a database connection pool? A
After a weekend without email a lot of things seems clear :-)
First, I believe we all have similar goals, and agree on most issues -
except some details. I think it is stupid to argue about them any more -
it's quite obvious that everyone is right in a certain context.
Everyone has an itch, and
Sam Ruby wrote:
> I'd like to see a proposal that can be voted on.
As to the codebase requirement for a proposal, would citing
DATASOURCE/DATABASE POOL
[Avalon/Cocoon2] DataSource Connection pool
[Struts] DataSource Connection pool
[Turbine] - Database Connection Pool
and
<
Ted Husted wrote:
>
> So, lets open a Jakarta Library CVS (Sam?), or a project
> on SourceForge, and start that ball rolling.
I'd like to see a proposal that can be voted on.
- Sam Ruby
"Geir Magnusson Jr." wrote:
> > I don't care whether you want to call it a repository or a catalog, but am
> > suggesting that perhaps we could simply start there?
>
> Yes. Great. Lets do that.
>
> Please.
OK, let's show some code, then.
The list of people who said they were interested in a J
Sam Ruby wrote:
> I'm trying to move away from hypotheticals and into specifics.
> So let me get REAL specific. First item on the agenda is what? I believe
> it is a database connection pool. And I believe that Struts has one of
> those. And I believe that you, Ted, have been known to play in
Sam Ruby wrote:
>
> Ted Husted wrote:
> >
> > So, you might as well be saying that Jakarta product is a failure
> > if it is not being used by another Jakarta product.
>
> I'm trying to move away from hypotheticals and into specifics.
>
> So let me get REAL specific. First item on the agenda i
Ted Husted wrote:
>
> So, you might as well be saying that Jakarta product is a failure
> if it is not being used by another Jakarta product.
I'm trying to move away from hypotheticals and into specifics.
So let me get REAL specific. First item on the agenda is what? I believe
it is a database
Sam Ruby wrote:
>
> Geir Magnusson Jr. wrote:
> >
> > I will use the DB COnnection Pool as an example of a component
> >
> > It is not required that the code come from existing Jakarta
> > projects...
> >
> > While nirvana would be achieved if Jakarta projects used these
> > products...
>
> I do
Sam Ruby wrote:
> Geir, would you be willing to concede that use by one or more (and
> preferably more than one) is an indication of success. In other words,
> which it may not be a reason in your eyes, it certainly is the desired
> result.
Not to interrupt, but Jakarta products are not the worl
Geir Magnusson Jr. wrote:
>
> I will use the DB COnnection Pool as an example of a component
>
> It is not required that the code come from existing Jakarta
> projects...
>
> While nirvana would be achieved if Jakarta projects used these
> products...
I don't believe that the above were taken out
> > 1) A central resource 'repository', as envisioned by Costin
> >(and others).
What would make this camp happiest, I think, is if we just automatically
enrolled everyone in Jakarta-Utils. This would give them a place to
break out code they wanted to share.
> > 2) A central component 'Cata
Sam Ruby wrote:
>
> Geir Magnusson Jr wrote:
> >
> > 1) A central resource 'repository', as envisioned by Costin
> >(and others).
> >
> > 2) A central component 'Catalog', as envisioned by myself
> >(and others).
>
> Perhaps I'm dense, but I really don't see a sharp dividing line between
> If the difference is whether or not we should include people
> whether or not
> they have expressed any desire to contribute, then I will
> openly admit that
> I don't see the point of automatic inclusion at this time.
>
Anybody needs non committed committers? :)
The last proposal made by
Geir Magnusson Jr wrote:
>
> 1) A central resource 'repository', as envisioned by Costin
>(and others).
>
> 2) A central component 'Catalog', as envisioned by myself
>(and others).
Perhaps I'm dense, but I really don't see a sharp dividing line between the
two.
Is the point of #1 to incl
Geir Magnusson Jr. wrote:
>
> > There are many people unsure of the wisdom of treating the
> > set of code bases as a whole, and insist on only building
> > their little corner of the world against stable, released
> > versions of everything else.
>
> But I agree with Costin here - no one in their
Why don't we fork this effort into two projects :
1) A central resource 'repository', as envisioned by Costin (and
others).
2) A central component 'Catalog', as envisioned by myself (and others).
We are spending so much time going back and forth like this, and I just
don't see that we are ever
Ceki Gülcü wrote:
>
> ps: I will be away for two weeks with no access to a computer. Just to let you
>know...
>
Lucky dog...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
Sam Ruby wrote:
> major issue. There are many people unsure of the wisdom of treating the
> set of code bases as a whole, and insist on only building their little
> corner of the world against stable, released versions of everything else.
> (Yes, Costin, this comment was directed at you ).
But
I took two days away from this for work and personal stuff... back now
:)
[EMAIL PROTECTED] wrote:
>
> > that will have essentially no operational or observable meaning. For
> > example, what does it mean to have someone listed as a committer who
> > doesn't participate? Conversely, under what
Sam Ruby wrote:
> through. That's how PHP development works. If you want a chuckle, take a
> look at:
>
>http://www.zend.com/zend/hof/sam.php
>
Did you take that picture yourself?
(I imagine you holding the camera...)
geir
--
Geir Magnusson Jr. [EMAIL PR
Sam Ruby wrote:
> Long term, I want to get to a state where there are low barriers to entry
> for those with value to contribute. In particular, I am particularly
> focused on the barriers between subprojects. Shorter term, I will gladly
> endorse any proposal that represents even a half-step t
Ted Husted wrote:
>
> I'm not sure what you are saying here, Sam.
>
> [snip]
>
> I consider everyone subscribed to this list to be
> acting committers.
I sense that there would be a number of people here who would be pleased if
this statement were to continue to hold true after a library proposal
Sam Ruby wrote:
> Currently there are zero committers. There seems to be an implicit
> assumption that if three or more people agree to work on something (each of
> you happen to be committers to some Jakarta project - you can decide
> whether or not that is relevant) then the code base and the c
Ted Husted wrote:
> Sam -- how do the PMC votes on new subprojects work? Would we vote
> +0 to approve only and +1 to approve and commit? Or is it just
> thumbs-up thumbs-down.
Traditionally, the PMC has voted +1 to approve, without any indication that
the individual would participate. One of p
[EMAIL PROTECTED] wrote:
> How about this:
>
> + Jakarta projects may also share existing packages by a 3/4 vote on the
> (origin) project, with at least 3 "commited" +1. The projects shared by
> jakarta projects do not need 3/4 aproval on the library list.
>
> After all the original project kno
> How about this:
>
> + New packages may be proposed to the library general list, and voted on
> by all the subproject committers. To be accepted, a package proposal
> must receive a positive 3/4's vote of the subproject
> committers. Proposals are to identify the scope of the package, the
> init
Federico Barbieri wrote:
> Ted Husted wrote:
> > I added you as a +1 to
> > Is that OK?
> Sure! Sorry but just solved the issue by wich I was receiving mails 1 or
> two days later they were sent! VERY annoyng!
> I'd just clarify the
> "New packages may be proposed to the library general list, and
"Ignacio J. Ortega" wrote:
> Please please put up a proposal for a rule the library that no ones can
> veto a new package for the simple reason that there is one that does the
> same job, :)
Now that you mention it, we did ask that question initially,
< http://husted.com/about/jakarta/lib002.ht
> I guess I don't understand why the util subproject is
> a special case. If I'm not allowed to vote on the
Because all projects will depend on it.
If you don't want your library shared - don't place it in
the shared repository.
> Servlet API, why can Servlet API committers vote on my
> libr
Morga Escribio:
> I'm just concerned that, if other subprojects (e.g.
> ServletApi, Turbine, Avalon, Tomcat, Taglibs, etc.
> etc. etc.) can vote/commit on our path, but we can't
The big misunderstanding here is that i dont want to create yet another
small set of committers with a clear and defin
> I'm just concerned that, if other subprojects (e.g.
> ServletApi, Turbine, Avalon, Tomcat, Taglibs, etc.
> etc. etc.) can vote/commit on our path, but we can't
> affect theirs, then ours is a ship with a dozen
> rudders and no sail. We're at the mercy of those
> groups arguing about their compe
I'm just concerned that, if other subprojects (e.g.
ServletApi, Turbine, Avalon, Tomcat, Taglibs, etc.
etc. etc.) can vote/commit on our path, but we can't
affect theirs, then ours is a ship with a dozen
rudders and no sail. We're at the mercy of those
groups arguing about their competing impleme
Morgan Escribio:
> I guess I don't understand why the util subproject is
> a special case. If I'm not allowed to vote on the
what ? i've send the message to the wrong list ? no this is library-dev
list :)
> Servlet API, why can Servlet API committers vote on my
> library? Let's not start rewr
That sounds reasonable.
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> For now, would this addition help?
>
> + Anyone may propose a new package to the library,
> and list themselves
> as the initial committers for the package. The vote
> on the proposal is
> then also a vote to enter new committer
I guess I don't understand why the util subproject is
a special case. If I'm not allowed to vote on the
Servlet API, why can Servlet API committers vote on my
library? Let's not start rewriting the rules, let's
just write some good software. If you really want a
stake in my library, monitor the
For now, would this addition help?
+ Anyone may propose a new package to the library, and list themselves
as the initial committers for the package. The vote on the proposal is
then also a vote to enter new committers to the subproject as needed.
I had actually thought this was implicit, but it
Costin escribio :
> How many commiters are listed in new-httpd commit file ? Do they have
> chaos ?
Why everybody assumes that giving 90 people access to the same
repository with accurate & strict rules as usual btw, produces
inherently Chaos?
Given that this people is already responsable in
At 14:01 23.02.2001 -0800, [EMAIL PROTECTED] wrote:
>> I totally share your views although I do not have the hindsight to
>> judge whether too many committers lead to chaos. Regards, Ceki
>
>Yes, everyone is scared of anarchy and chaos - but all I can see is the
>chaos due to many small projects w
> I totally share your views although I do not have the hindsight to
> judge whether too many committers lead to chaos. Regards, Ceki
Yes, everyone is scared of anarchy and chaos - but all I can see is the
chaos due to many small projects with mini-communities that are not able
to communicate wit
At 13:27 23.02.2001 -0800, [EMAIL PROTECTED] wrote:
>> This is coming from a person who wants to simultaneously give 90+ people
>> karma to the core components upon which everybody will be asked to depend.
>
>The problem was never that too many people have access to a
>component, but that too few
> This is coming from a person who wants to simultaneously give 90+ people
> karma to the core components upon which everybody will be asked to depend.
The problem was never that too many people have access to a
component, but that too few people.
How many commiters are in tomcat ? How many are
Costin Manolache wrote:
>
> I know my limits, and I have a bit of experience building
> projects - I'm sorry, but dealing with all the changes at
> once is over my capacity, so I'll have to stay in a little
> corner where I know that at only few walls are moving.
LOL!
This is coming from a pers
> Costin Manolache wrote:
> >
> > This whole "become a commiter" is not that easy
>
> Tell me about it. Perhaps you remember when I first tried to get a few
> patches applied to a subproject named Tomcat. ;-)
I'm glad you still remember ! And at least one person on this list
understands ( or s
Costin Manolache wrote:
>
> This whole "become a commiter" is not that easy
Tell me about it. Perhaps you remember when I first tried to get a few
patches applied to a subproject named Tomcat. ;-)
> My feeling is that the bariers between "normal" jakarta projects
> are too high.
Warning: I su
> that will have essentially no operational or observable meaning. For
> example, what does it mean to have someone listed as a committer who
> doesn't participate? Conversely, under what circumstances do we see
> someone interested in contributing and with a prior history with other
> Jakarta p
> Finally, it is my hope that the end result of this effort is that the walls
> between projects that people see as much harder barriers than they really
> are will become more porous, with both people and code flowing more freely
> between them. Much talk has been given to people getting commit
> At this point, most people seemed to want to start with the JDBC
> pool. I also suggested we also work on a testing framework, along
> with the support structure.
I am interested in the last 2.
Regarding the testing framework - I don't know what will be the schedule,
tomcat3.3 needs it _no
Sam Ruby wrote:
> Finally, it is my hope that the end result of this effort is that the walls
> between projects that people see as much harder barriers than they really
> are will become more porous, with both people and code flowing more freely
> between them.
+1
Personally, I believe the be
> Sam's other recent "steering" comments are here:
LOL! Pretty accurate, though. I very much want this project to get off
the ground though volunteer efforts, not by a PMC mandate.
A general comment: some of the "discussions" here are over distinctions
that will have essentially no operational
Morgan Delagrange wrote:
>
> Hi all,
>
> Maybe it's time for a reset here? Instead of worrying
> so much about other subprojects, why don't we focus on
> creating good stand-alone libraries? After all, we
> can't force anybody to adopt our libraries if they
> don't want to. Even if only some
Morgan Delagrange wrote:
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off?
At this point, most people seemed to want to start with the JDBC
pool. I also suggested we also work on a testing framework, along
with the suppo
Morgan Delagrange wrote:
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off? Really, if we don't work in a small group,
> it's going to be group-vs.-group-vs.-group,
> my-framework-is-better-than-your-framework, and
> nothing
65 matches
Mail list logo
