You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Glen Stampoultzis <gs...@iinet.net.au> on 2004/08/04 07:31:09 UTC
[VOTE] POI 2.5.1 release
I've collected a bunch of changes together and created a maintenance release.
A preview copy may be found here:
http://cvs.apache.org/~glens/release/
This does not include any changes being made in the head.
[ ] +1 Go ahead and release
[ ] +0 Sure... whatever
[ ] -0 I have some reservations (name them)
[ ] -1 VETO. We can not release this.
Glen Stampoultzis
gstamp@iinet.net.au
http://members.iinet.net.au/~gstamp/glen/
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
Posted by ac...@apache.org.
I don't think there is a cognitive chasm. Its parallel arrays of
primitives. Start there and say "what would be necessary to have the most
compact structure possible for parallel arrays of primitives" and the rest
works itself out. This is nothing compared to what we need to do for memory
mapping! Now that kinda thing rots the brain entirely. Doing such in POIFS
is one thing but HSSF to quote Bill and Ted....whoa...dude.
--
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: Avik Sengupta <av...@itellix.com>
> Reply-To: "POI Developers List" <po...@jakarta.apache.org>
> Date: Fri, 06 Aug 2004 17:34:16 +0530
> To: POI Developers List <po...@jakarta.apache.org>
> Subject: Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
>
> 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, cwakefield@mdanderson.org 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 <av...@itellix.com>
>> 08/05/04 10:40 AM
>> Please respond to "POI Developers List"
>>
>>
>>
>> To:
>> POI Developers List <po...@jakarta.apache.org>
>> 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: poi-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: poi-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: poi-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
Posted by Avik Sengupta <av...@itellix.com>.
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, cwakefield@mdanderson.org 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 <av...@itellix.com>
> 08/05/04 10:40 AM
> Please respond to "POI Developers List"
>
>
>
> To:
> POI Developers List <po...@jakarta.apache.org>
> 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: poi-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: poi-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
Posted by ac...@apache.org.
Agreed moreover if something goes wrong in the CVS process then there is
less pressure. It doesn't make a lot of sense to wait.
--
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 <gs...@iinet.net.au>
> Reply-To: "POI Developers List" <po...@jakarta.apache.org>
> Date: Fri, 06 Aug 2004 22:35:29 +1000
> To: "POI Developers List" <po...@jakarta.apache.org>
> Subject: Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
>
> At 02:35 PM 5/08/2004, you wrote:
>> Ideally the HEAD-based release would contain Glen's latest changes.
>> However, if 1. and 2. take too long it would be better to make a 2.5.1
>> immediately and a 2.6 release later (but not too late).
>
> 2.5.1 is essentially good to go as it is so my plan is to put it up.
>
>> Do we formally need to vote on this? Are there any other issues?
>
> No. I think we're good to go.
>
>
>
>
> Glen Stampoultzis
> gstamp@iinet.net.au
> http://members.iinet.net.au/~gstamp/glen/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
Posted by Glen Stampoultzis <gs...@iinet.net.au>.
At 02:35 PM 5/08/2004, you wrote:
>Ideally the HEAD-based release would contain Glen's latest changes.
>However, if 1. and 2. take too long it would be better to make a 2.5.1
>immediately and a 2.6 release later (but not too late).
2.5.1 is essentially good to go as it is so my plan is to put it up.
>Do we formally need to vote on this? Are there any other issues?
No. I think we're good to go.
Glen Stampoultzis
gstamp@iinet.net.au
http://members.iinet.net.au/~gstamp/glen/
Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
Posted by Rainer Klute <kl...@rainer-klute.de>.
Am Do, den 05.08.2004 schrieb Danny Mui um 1:17:
> The perf branch should still be a target to convert to, but I agree that
> things are stagnating and drifting too far apart.
It seems we have consensus on these items:
1. From the HEAD fork a new "performance branch", say, HSSF_PERF,
containing the current unstable HSSF changes. Advantages:
- We have only stable modules in the HEAD, which should be a must in the
future. Stable means that the code compiles, that there are sufficient
test cases, and that the test cases don't fail.
- The performance development could continue in the HSSF_PERF branch
without any time pressures. The changes can be merged into the HEAD when
they are finished. Whether that merging is easy or not and whether any
HSSF changes that are unrelated to the performance thing have to be done
to both HEAD and HSSF_PERF, I cannot decide.
2. Copy HSSF from the REL_2_BRANCH to the HEAD.
3. Make a HEAD-based release fairly soon.
Ideally the HEAD-based release would contain Glen's latest changes.
However, if 1. and 2. take too long it would be better to make a 2.5.1
immediately and a 2.6 release later (but not too late).
Do we formally need to vote on this? Are there any other issues?
Best regards
Rainer Klute
Rainer Klute IT-Consulting GmbH
Dipl.-Inform.
Rainer Klute E-Mail: klute@rainer-klute.de
Körner Grund 24 Telefon: +49 172 2324824
D-44143 Dortmund Telefax: +49 231 5349423
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
Posted by Danny Mui <da...@muibros.com>.
Interesting take there with numbers ;).
The HEAD has a lot of changes in there that make it look a lot different
from REL 2. I tried to get basic read/write functionality going but ran
into a nice firm wall :). I think if we can get that back and working
we can merge all the features/bug fixes a lot easier.
Having said all that familiarity is still nice.
The perf branch should still be a target to convert to, but I agree that
things are stagnating and drifting too far apart.
cwakefield@mdanderson.org 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 <av...@itellix.com>
> 08/05/04 10:40 AM
> Please respond to "POI Developers List"
>
>
>
> To:
> POI Developers List <po...@jakarta.apache.org>
> 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: poi-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: poi-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
Posted by cw...@mdanderson.org.
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 <av...@itellix.com>
08/05/04 10:40 AM
Please respond to "POI Developers List"
To:
POI Developers List <po...@jakarta.apache.org>
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: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Plans etc (was Re: [VOTE] POI 2.5.1 release )
Posted by Avik Sengupta <av...@itellix.com>.
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: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: [VOTE] POI 2.5.1 release
Posted by ac...@apache.org.
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 <gs...@iinet.net.au>
> Reply-To: "POI Developers List" <po...@jakarta.apache.org>
> Date: Wed, 04 Aug 2004 21:16:49 +1000
> To: "POI Developers List" <po...@jakarta.apache.org>
> 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: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: [VOTE] POI 2.5.1 release
Posted by Glen Stampoultzis <gs...@iinet.net.au>.
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
Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release
Posted by ac...@apache.org.
I understand your concerns. It is also unfair to hold your work up.
Initially I thought I'd be given a greater amount of time to do the HSSF
refactoring, but its not looking promising and HSSF isn't stable in the
head. Therefore, I think we should overwrite the HSSF part of the HEAD wit=
h
the 2.5 stuff (possibly branching first to preserve it). While many folks
have given promising (2/3 memory footprint reduction) feedback on the memor=
y
savings, no contributors or even fellow committers have stepped forward to
help and I can't really do that myself and keep it in synch. Thoughts?
--=20
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: Rainer Klute <kl...@rainer-klute.de>
> Organization: Rainer Klute IT-Consulting GmbH
> Reply-To: "POI Developers List" <po...@jakarta.apache.org>
> Date: Wed, 04 Aug 2004 08:40:17 +0200
> To: POI Developers List <po...@jakarta.apache.org>
> Subject: Re: [VOTE] POI 2.5.1 release
>=20
> On Wed, 2004-08-04 at 07:31, Glen Stampoultzis wrote:
>> I've collected a bunch of changes together and created a maintenance rel=
ease.
>=20
> Glen, first of all thank you for your changes and your effort to create
> a maintenance release!
>=20
>=20
>> This does not include any changes being made in the head.
>=20
> 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.
>=20
> 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.
>=20
>=20
> Regarding my vote:
>=20
>> [ ] +1 Go ahead and release
>> [X] +0 Sure... whatever
>> [ ] -0 I have some reservations (name them)
>> [ ] -1 VETO. We can not release this.
>=20
>=20
> Best regards
> Rainer Klute
>=20
> Rainer Klute IT-Consulting GmbH
> Dipl.-Inform.
> Rainer Klute E-Mail: klute@rainer-klute.de
> K=F6rner Grund 24 Telefon: +49 172 2324824
> D-44143 Dortmund Telefax: +49 231 5349423
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: poi-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: [VOTE] POI 2.5.1 release
Posted by ac...@apache.org.
+1 to the release.=20
Response to Rainer will be in another mail.
--=20
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: Rainer Klute <kl...@rainer-klute.de>
> Organization: Rainer Klute IT-Consulting GmbH
> Reply-To: "POI Developers List" <po...@jakarta.apache.org>
> Date: Wed, 04 Aug 2004 08:40:17 +0200
> To: POI Developers List <po...@jakarta.apache.org>
> Subject: Re: [VOTE] POI 2.5.1 release
>=20
> On Wed, 2004-08-04 at 07:31, Glen Stampoultzis wrote:
>> I've collected a bunch of changes together and created a maintenance rel=
ease.
>=20
> Glen, first of all thank you for your changes and your effort to create
> a maintenance release!
>=20
>=20
>> This does not include any changes being made in the head.
>=20
> 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.
>=20
> 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.
>=20
>=20
> Regarding my vote:
>=20
>> [ ] +1 Go ahead and release
>> [X] +0 Sure... whatever
>> [ ] -0 I have some reservations (name them)
>> [ ] -1 VETO. We can not release this.
>=20
>=20
> Best regards
> Rainer Klute
>=20
> Rainer Klute IT-Consulting GmbH
> Dipl.-Inform.
> Rainer Klute E-Mail: klute@rainer-klute.de
> K=F6rner Grund 24 Telefon: +49 172 2324824
> D-44143 Dortmund Telefax: +49 231 5349423
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: poi-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: [VOTE] POI 2.5.1 release
Posted by Rainer Klute <kl...@rainer-klute.de>.
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.
Regarding my vote:
> [ ] +1 Go ahead and release
> [X] +0 Sure... whatever
> [ ] -0 I have some reservations (name them)
> [ ] -1 VETO. We can not release this.
Best regards
Rainer Klute
Rainer Klute IT-Consulting GmbH
Dipl.-Inform.
Rainer Klute E-Mail: klute@rainer-klute.de
Körner Grund 24 Telefon: +49 172 2324824
D-44143 Dortmund Telefax: +49 231 5349423
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
RE: [VOTE] POI 2.5.1 release
Posted by Shawn Laubach <sh...@cox.net>.
+1
-----Original Message-----
From: Glen Stampoultzis [mailto:gstamp@iinet.net.au]
Sent: Wednesday, August 04, 2004 12:31 AM
To: poi-dev@jakarta.apache.org
Subject: [VOTE] POI 2.5.1 release
I've collected a bunch of changes together and created a maintenance
release.
A preview copy may be found here:
http://cvs.apache.org/~glens/release/
This does not include any changes being made in the head.
[ ] +1 Go ahead and release
[ ] +0 Sure... whatever
[ ] -0 I have some reservations (name them)
[ ] -1 VETO. We can not release this.
Glen Stampoultzis
gstamp@iinet.net.au
http://members.iinet.net.au/~gstamp/glen/
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org