(sorry for this being very late and out of sequence: blueyonder has been
v poor all week)
On Fri, 2005-12-02 at 21:00 -0500, Henri Yandell wrote:
On 12/2/05, Martin Cooper [EMAIL PROTECTED] wrote:
IMO, what this tells us is the Commons isn't scaling, and that doesn't
surprise me at all.
Hi all,
Like your list Henri. Here is my list (with some overlap..)
My ideas to improve things are :
- Move sandbox components to the background (at least on the commons page). If
the components are worthy, they will pick up interest without it. For now it
looks like just another list of
On 12/2/05, Martin Cooper [EMAIL PROTECTED] wrote:
snip
In the old days we kept lf line endings on all the source files in
cvs and hand-rolled ant scripts were used to put crlf on the .txt
files in the zips. Between maven and svn's eol=native, that is no
longer possible or at least
On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote:
On 12/2/05, Martin Cooper [EMAIL PROTECTED] wrote:
snip
In the old days we kept lf line endings on all the source files in
cvs and hand-rolled ant scripts were used to put crlf on the .txt
files in the zips. Between maven and svn's
On 12/1/05, Martin van den Bemt [EMAIL PROTECTED] wrote:
snip
To reask the question in this thread : what is broken with crlf ?
I use both windows and linux (and mix zips and tgz on both platforms) and
never had a single issue with this. It could be the way I work though :)
That is a good
On 11/30/05, Mario Ivankovits [EMAIL PROTECTED] wrote:
Phil Steitz wrote:
For me +1 means pretty much what Martin describes above. I check the
release contents, make sure required elements are there and in jars,
make sure there is nothing funny included. I test the builds,
validate
Phil Steitz wrote:
In the old days we kept lf line endings on all the source files in
cvs and hand-rolled ant scripts were used to put crlf on the .txt
files in the zips. Between maven and svn's eol=native, that is no
longer possible or at least immediate. The real question (see other
On 12/2/05, Phil Steitz [EMAIL PROTECTED] wrote:
One other comment that I have on the issue of voting on releases is
that the core problem here is lack of component-committed volunteers,
IMHO. I remember a couple of years back when we discussed whose votes
were binding on component releases.
On 12/2/05, Niall Pemberton [EMAIL PROTECTED] wrote:
On 12/2/05, Phil Steitz [EMAIL PROTECTED] wrote:
I will start. All I can really support right now are [math], [lang],
[collections] in commons proper and [id] in sandbox. One day when I
have more time and courage, I would like to jump
On 12/2/05, Phil Steitz [EMAIL PROTECTED] wrote:
On 11/30/05, Mario Ivankovits [EMAIL PROTECTED] wrote:
Phil Steitz wrote:
For me +1 means pretty much what Martin describes above. I check the
release contents, make sure required elements are there and in jars,
make sure there is
On 12/2/05, Martin Cooper [EMAIL PROTECTED] wrote:
IMO, what this tells us is the Commons isn't scaling, and that doesn't
surprise me at all. In the old days, there were a *lot* fewer components.
Right now, I count 35 components in Proper and 9 more active components in
the Sandbox (excluding
On 12/1/05, Phil Steitz [EMAIL PROTECTED] wrote:
On 11/30/05, Martin Cooper [EMAIL PROTECTED] wrote:
On 11/30/05, Niall Pemberton [EMAIL PROTECTED] wrote:
On 12/1/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
Release managers are also facing tougher release checkers now IMHO. For
similarities (e.g. composition functions).
Tim.
-Original Message-
From: Niall Pemberton [mailto:[EMAIL PROTECTED]
Sent: 01 December 2005 08:40
To: Jakarta Commons Developers List
Subject: Re: [all] Together, and bricks apart
On 12/1/05, Phil Steitz [EMAIL PROTECTED] wrote:
On 11/30
: RE: [all] Together, and bricks apart
+1 (can't really say non-binding ;-)
Would also like to help revive sandbox functor if I have time. Whats needs
to be done to get it this project into commons proper and build a community?
Someone else made the point that it would be good to know what needs
At least one of you release checkers ;-) should setup a wiki to
describe every step to do, this helps the release manager and those
checking it.
Especially if you are a newbie in the release cycle it might be a great
start AND it defines standards.
I like Marios idea.
Very new to
Mario Ivankovits wrote:
Phil Steitz wrote:
Thats true, I'll learn with every release review too, but can do this
only if another one complains about this and that.
If I read the stuff you do to check a release I am shocked, damn much
work to do.
At least one of you release checkers ;-)
I hope I'm not wrong on this. If I am, and you're right, Niall, then I might
as well give up on ever getting another FileUpload release out the door,
based on how few people other than myself have ever touched the code base
over the last several years.
Just about FileUpload : in the coming
On 11/30/05, Rahul Akolkar [EMAIL PROTECTED] wrote:
I'm also seeing a trend that is a tad disappointing. The last three
successive release votes each needed to make pleas for a better
response from the developer community. We've witnessed this for, in
chronological order:
* VFS [1]
*
On 11/30/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
You are certainly correct in spotting these cases, however other votes
will also go through. One of the big issues I have with Apache is the
amount of procedure and boring stuff necessary to go through to get a
release released.
The
Martin van den Bemt wrote:
I tend to focus more on (for me) productive things, since (almost) all
of my open source efforts happens/has to happen in my spare time,
which is limited..
Me too, especially the [vfs] thing is a free time job for me. But even
more it is demotivating if you are
Mario Ivankovits wrote:
I search a little bit, and guess what, we have such a documentation
http://jakarta.apache.org/commons/releases/prepare.html
We have to rework it, tough.
*) In the area of class file format we should state that we not allow
to use only the target attribute but also
Mario Ivankovits wrote:
Martin van den Bemt wrote:
I tend to focus more on (for me) productive things, since (almost) all
of my open source efforts happens/has to happen in my spare time,
which is limited..
Me too, especially the [vfs] thing is a free time job for me. But even
more it is
Stephen Colebourne wrote:
Mario Ivankovits wrote:
I search a little bit, and guess what, we have such a documentation
http://jakarta.apache.org/commons/releases/prepare.html
We have to rework it, tough.
*) In the area of class file format we should state that we not
allow to use only
I believe Jakarta Commons (especially the sandbox) is one of the
wonderful playgrounds we have under the Apache umbrella. Having
started a sandbox project recently, I continue to be amazed by the
Commons community and its responsiveness in day-to-day operations.
I'm also seeing a trend that is a
Rahul Akolkar wrote:
I'm also seeing a trend that is a tad disappointing. The last three
successive release votes each needed to make pleas for a better
response from the developer community.
I'm afraid it might be easy to misunderstand or ridicule this email,
point to the some Apache voting
On 12/1/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
Release managers are also facing tougher release checkers now IMHO. For
instance, I haven't ignored configuration, but haven't had the time to
check it out properly (way too much to do). I try to only give a +1 if I
genuinely am happy.
On 11/30/05, Niall Pemberton [EMAIL PROTECTED] wrote:
On 12/1/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
Release managers are also facing tougher release checkers now IMHO. For
instance, I haven't ignored configuration, but haven't had the time to
check it out properly (way too much
On 11/30/05, Martin Cooper [EMAIL PROTECTED] wrote:
On 11/30/05, Niall Pemberton [EMAIL PROTECTED] wrote:
On 12/1/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
Release managers are also facing tougher release checkers now IMHO. For
instance, I haven't ignored configuration, but
Phil Steitz wrote:
For me +1 means pretty much what Martin describes above. I check the
release contents, make sure required elements are there and in jars,
make sure there is nothing funny included. I test the builds,
validate sigs, etc and inspect the web site and, if present,
clirr/jdiff
29 matches
Mail list logo
