Mailing-List: contact poi-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "POI Developers List" <poi-dev@jakarta.apache.org>
Message-Id: <6.0.0.22.0.20040804204820.033c7708@localhost>
Date: Wed, 04 Aug 2004 21:16:49 +1000
To: "POI Developers List" <poi-dev@jakarta.apache.org>
From: Glen Stampoultzis <gstamp@iinet.net.au>
Subject: Re: [VOTE] POI 2.5.1 release
In-Reply-To: <1091601617.9103.28.camel@tommy.rainer-klute.de>
References: <6.0.0.22.0.20040804152608.01df88f8@localhost>
 <1091601617.9103.28.camel@tommy.rainer-klute.de>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_165166562==.ALT"

--=====================_165166562==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:40 PM 4/08/2004, you wrote:
>On Wed, 2004-08-04 at 07:31, Glen Stampoultzis wrote:
> > I've collected a bunch of changes together and created a maintenance 
> release.
>
>Glen, first of all thank you for your changes and your effort to create
>a maintenance release!
>
>
> > This does not include any changes being made in the head.
>
>I don't mind another maintenance release, but I'd also like to see a
>release with the "new" features that are in the head. For example, the
>HPSF capability to write properties is not in any release but only in
>the head for months if not for a year or so. HPSF's codepage handling is
>also in the head only for months.
>
>I suspect that many users don't know that these features exist because
>they just download a release and don't bother to checkout the CVS' head.

Yes.  I would also like a release of head.  The main problem we face with 
this is that HSSF is very broken in the trunk.  The performance work that 
was initially done was not complete.  I did a bit of work earlier to try to 
fix some of the issues but there is still more that needs to be done and no 
one is particularly motivated to fix it as it's fairly hard to know where 
to start.  Meanwhile it gets harder and harder to backport fixes to head as 
the branch gets further out of line.  As I see it we have the following 
options:

1. Continue working on the trunk and backport any changes that haven't gone 
into the trunk yet.
2. Copy HSSF from the branch to trunk and overwrite the performance/memory 
changes.
3. Copy HSSF from the branch to trunk and come up with some more 
incremental ways to reduce memory.
4. Pretend nothing is wrong and go about the way we've been going.

I don't like any of these options much.

(1) involves a lot of work and will probably take a while to stabilize but 
preserves what has been done so far.
(2) is easy and gets us back to a sane state but means all those memory 
improvements are now lost to us.
(3) would be good but involves finding quick wins.  There may be none to be 
found.  I've been doing a little work in the background experimenting with 
less obtrusive ways to conserve memory but it's too early to tell if 
they'll be effective.
(4) really doesn't isn't an option.  We need to do something or the project 
is in trouble.

So consider this an open discussion (non-committers welcome to chime in) 
about each option.  If you're willing to help out in getting things back on 
track then let us know what you might be able to contribute.

Here are some rules of thumb I'd like us to apply in the future:

1. No long lived branches.  Branches are for minor patches to 
releases.  Experimenting in branches is okay but don't expect it to form 
part of a release until it is solid.
2. No checking in of broken code.
3. Incremental changes are best.


Regards,

Glen


--=====================_165166562==.ALT--