Little history,
about 6 months ago I added build support to Alexandria. It seemed to
make sense that since I wanted to test build and Alexandria already had a
means getting hold of the source from cvs without to much hassle it seemed
good to just added in the ability to kick off a
[EMAIL PROTECTED] typed the following on 04:17 PM 2/15/2001 -0800
Seriously speaking - I am very concerned with the content of the library -
I have a feeling that some people would like one book for each subject. I
think that would be a very big step backwards.
My hope is that the "library"
[EMAIL PROTECTED] wrote:
Seriously speaking - I am very concerned with the content of the library -
I have a feeling that some people would like one book for each subject. I
think that would be a very big step backwards.
My hope is that the "library" project will be organized in a way that
Sam Ruby wrote:
the name of the mailing list should match the name of the
subproject. I'm willing to create the mailing list in anticipation of the
project being created, but it like to be sure that the name is what
everybody wants.
The name is one of the things we would discuss on the
My hope is that the "library" project will be organized in a way that
allows multiple "books" in each collection.
I agree, it's important to allow different ideas to flower rather than impose
a "one true way" philosophy. But I also think it's important to keep strong
quality control on
My own hope is that each component be treated like a book, with it's own
publication date, edition count, and set of authors and editors.
And again - we'll act as librarians and make sure the book is available,
not as censors or authors of competing books.
For this branch, we probably need
[EMAIL PROTECTED] wrote:
The project should _host_ and maintain code that is shared by projects,
not _develop_ utils that may be needed ( like CPAN, or alexandria ).
How can that work in the current "project committer" model? I agree
that it should be open to accept projects from the
[EMAIL PROTECTED] wrote:
If someone chooses to duplicate a piece of code, maybe the problem is with
the way the code is written and shared.
I think in some cases, its bacause people aren't aware that the stuff
exists. Go through the Jakarta project sites, and find the number of
places that
"Geir Magnusson Jr." wrote:
Jakarta is rich in general-use tools. We just need to get them out into
the light of day, documented, and supported directly, not incidentally
as part of larger projects.
I believe you and I are on the same page, Geir. Costin wants to go a
different way with this.
The project should _host_ and maintain code that is shared by projects,
not _develop_ utils that may be needed ( like CPAN, or alexandria ).
How can that work in the current "project committer" model? I agree
that it should be open to accept projects from the 'outside', but I
think
If someone chooses to duplicate a piece of code, maybe the problem is with
the way the code is written and shared.
I think in some cases, its bacause people aren't aware that the stuff
exists. Go through the Jakarta project sites, and find the number of
places that offer a separate,
[EMAIL PROTECTED] wrote:
If someone chooses to duplicate a piece of code, maybe the problem is with
the way the code is written and shared.
I think in some cases, its bacause people aren't aware that the stuff
exists. Go through the Jakarta project sites, and find the number of
"Geir Magnusson Jr." wrote:
[EMAIL PROTECTED] wrote:
If someone chooses to duplicate a piece of code, maybe the problem is with
the way the code is written and shared.
I think in some cases, its bacause people aren't aware that the stuff
exists. Go through the Jakarta project sites,
Hear hear! I think that Taglibs is an excellent model
for a library-oriented subproject. Here are some
features of Taglibs (some overlap with Craig's
comments) that I think would translate quite well:
* individual landing pages for each taglib
(essentially sub-subprojects)
*
14 matches
Mail list logo
