Please don't continue this discussion in the VOTE thread. I started a new thread. -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi For Java and Excel, Got POI? > From: Glen Stampoultzis <[EMAIL PROTECTED]> > Reply-To: "POI Developers List" <[EMAIL PROTECTED]> > Date: Wed, 04 Aug 2004 21:16:49 +1000 > To: "POI Developers List" <[EMAIL PROTECTED]> > Subject: Re: [VOTE] POI 2.5.1 release > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
