poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cwakefi...@mdanderson.org
Subject Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
Date Wed, 04 Aug 2004 22:03:24 GMT

One of you said "Chime in", so I am.  (No I haven't contributed before...)

I thought that before I suggested option 1,2,3, or 4, I would try to see 
what was really at issue, which led to a little analyzing:

(If I understand what is in CVS now, the branch you are referring to is 
the one tagged REL_2_BRANCH, and head is HEAD - which also seems to be 
MAIN, and jakarta-poi.)
A quick compare of these shows:

5 .java files in REL_2_BRANCH not in HEAD.
119 .java files in HEAD not in REL_2_.
300 .java files that have differences, BUT...
it looks like most of those 300 (90%+ ?), the only difference is in blank 
lines around the copyright notice or changes in comments, 
which leaves less than 30 java files where functionality has to be 

If this is right, option #1 now seems less ominous than it did. 
I know I am assuming that I'm even looking at the right branch, which 
hasn't been obvious.  I'm also only counting differences in the .java 

Am I way off base here?  If my impression is even close to realistic, I'd 
be glad to help with merging changes from REL_2 into HEAD. 

Chris Wakefield

Avik Sengupta <avik.sengupta@itellix.com>
08/05/04 10:40 AM
Please respond to "POI Developers List"


POI Developers List <poi-dev@jakarta.apache.org>

Plans etc (was Re: [VOTE] POI 2.5.1 release )


Thanks for setting the agenda. 

I agree that no. 4. isnt really an option. 

Option 1 is getting more and more difficult each day. Till about the 2.5
delivery, most changes were getting backported. But I think some recent
fixes havent been. And I think it is infeasible to expect outside
contributors to provide patches for both branches, which leaves
committers with double the work to do. Thus, I think unless we are sure
of getting HEAD in a fixable state very soon (which doesnt seem very
likely at the moment), this will only get worse.

Which I think essentially leaves us with a mix of options 2 and 3. I say
this with some sadness, since the trunk contains some good stuff, and I
have been thinking about this for a while. I think we are currently in a
state of paralysis, and really need to getmoving... all the good stuff
cant help us if we get stuck. 

Technically, the performance changes affect POIFS as well, AFAIK.
Therefore, it would be better to copy HPFS and HWPF to branch, and copy
the resulting back to HEAD.. but thats just an implementation detail. 

So my suggestion is take option 2 immediately, and work towards 3 after

And finally, agree 100% on the rules of thumb.. 

On Wed, 2004-08-04 at 16:46, Glen Stampoultzis wrote:
> 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 
> >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' 
> Yes.  I would also like a release of head.  The main problem we face 
> this is that HSSF is very broken in the trunk.  The performance work 
> was initially done was not complete.  I did a bit of work earlier to try 
> fix some of the issues but there is still more that needs to be done and 
> one is particularly motivated to fix it as it's fairly hard to know 
> to start.  Meanwhile it gets harder and harder to backport fixes to head 
> 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 
> into the trunk yet.
> 2. Copy HSSF from the branch to trunk and overwrite the 
> 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 
> 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 
> found.  I've been doing a little work in the background experimenting 
> 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 
> 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 
> 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: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message