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]
