Interesting analysis, for sure. However, I'm not sure its as easy as it sounds. Essentially, the way in which the underlying records are being stored has changed (from create at startup to create and/or spoof on demand) Which is quite cool, but breaks many higher level functionality that depend on a different set of assumptions. Also, that has created a cognitive gap that not many have been able to cross, whereby its been difficult to fix the broken functionality.
So its not a case of CVS merge.. essentially, some functionality needs to be re-written to the new way... - avik On Thu, 2004-08-05 at 03:33, [EMAIL PROTECTED] wrote: > Greetings! > > 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 > reconciled. > > 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 > files. > > 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. > > > Regards, > Chris Wakefield > > > > > > > > > > Avik Sengupta <[EMAIL PROTECTED]> > 08/05/04 10:40 AM > Please respond to "POI Developers List" > > > > To: > POI Developers List <[EMAIL PROTECTED]> > cc: > > Subject: > Plans etc (was Re: [VOTE] POI 2.5.1 release ) > > > > Glen, > > 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 > that. > > 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 > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
