You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Andrew C. Oliver" <ac...@nc.rr.com> on 2002/01/11 16:52:58 UTC

Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI serializers/generators)

On Fri, 2002-01-11 at 05:35, Gianugo Rabellino wrote:
> Nicola Ken Barozzi wrote:
> 
> >>Don't get me wrong, I'm really happy about POI being part of the game,
> >>but I'd like to have a good reason for having tons of daily patches
> >>coming in, or as far as I'm concerned they will be confined to
> >>scratchpad for a long time. :-)
> >>
> > 
> > IMHO think it's unfair, given the importance of the project.
> > POI is in 1.0 version, I don't think you will want it in scratchpad for
> > long, as many users will be asking continuously how to install it.
> > My 2cents, of course ;-)
> 
> 
> This (IMNSHO ;)) is perfectly fair to users. I agree and wish that many 
> people will be using it, yet if the thing is going through such a 
> massive bugfixing as the one you are outlining:
> 
>  > The fact is that bugfixes are very very frequent, 'cause we're
>  > dealing with an undocumented (badly anyway) file format and
>  > many M$ product versions.
> 

Ken:  Whoa?  Bugfixes are frequent?  How come no one told me?..

Seriously we've had 1 minor, 1 major, and one trivial MS-blameable issue
since the stable release.

These would not have gotten us to 1.0.2 except that the minor bug was
reported just as the 1.0.1 announcement was going out.  I think it is
unfair to characterize this as "very very frequent".  

Secondly, these were ALL API issues and none were serializer issues.  

I disagree with Ken that MS was to blame for these (except for the
trivial issue).  I blame 1.0 releases and production data for these
:-D.  The two more serious bugs were in the Static String table (in
short cells contain a reference to a blocked set of string data).  

Getting this algorythm right was very difficult and testing was very
extensive.  That being said: nothing breaks code like REAL world data.  
Had we not done a 1.0.0 release, then these would have NEVER been
discovered (well Marc feels we should have had a super duper long string
unit test, but I consoled him, no use in crying over spilled milk).

We had a second bugfix release because the first was on its way out the
door as while other was being reported.  The bug covered in the 1.0.1
was more serious and intermittent and I absolutely HATE intermittent
bugs so we decided to go ahead and ship it (1.0.1), while we fixed the
more minor bug which only affected people who write longer strings then
this email into a single cell (which I would bet/hope is a minority
:-p), but it was important to "get it right" in the production code.  So
both were in the same area of (API) code, and it is the one of the most
complex pieces of the whole thing.  (If anyone wants to know more, just
ask. I just don't know everyone finds this as interesting as I do and
I'm trying not to get sidetracked in my emails :-D)

I posted a very trivial patch to the poi-users list before the 1.0.2 was
released (though it was in testing mode), due to a Microsoft Office
service pack issue.  Meaning, my stock version doesn't do this (I run it
through VMWare...I'm 100% UNIX/Linux to the core of my cold dark black
soul :-D).  The issue being an annoying dialog box comes up and says
there is a potential security issue with POI::HSSF generated files. 
This was a single boolean value change and does not warrant another
bugfix release.  (We'll queue this and any other issues and do one
sometime midway though the development cycle).  While I can't justify a
release for a boolean value change :-) I had to sympathize with some
poor guy like me whose user-community asks him if the reporting system
he wrote is sending them viruses so the patch is available to those who
need it.


> this makes me wonder why POI is labeled as 1.0 if there is such a huge 
> amount of needed patches going on... in second place this might lead to 
> undesired countereffects, with users having to resort to CVS updates to 
> get a working Cocoon+POI setup. In other words: are we targeting users 
> (which means stable tree + included jars) or developers/hackers? If we 
> go for the second than people that can use CVS can also live with a 
> scratchpad component.
> 

My answer: both if you're talking about the APIs (this is very confusing
for the moment).  We have 2 branches.  Stable and Development just like
Cocoon does.  The POI user community is not particularly patient.  We're
working on adding formula support to HSSF (for 2.0) and people are
writing asking if we can skip that and just go straight to Pivot tables
:-p.  So the development builds of the API are there to those who need
them.

For the serializer: I'm not opposed to doing hacker releases if someone
can convince me that there is a compelling reason to do so, but my focus
is to get the APIs stable for each release then expose the APIs via the
serializers and generators.  While thats just my opinion I think it is
the general consensus in the POI family :-D.

I even go so far as to keep the Serializer and generator a bit behind
the API.  My "wearing the user-hat" perspective of this is that I'd
rather have something WORK reliably or not be provided at all when I'm
working in XML.  Our API user community tends to use the development
builds and flush out bugs very fast and for that we are very grateful. 
This greatly adds to the stability of the serializer provided it is kept
a little behind.  

The only reason I can think of for a hacker release is some new concept
or something.  This won't happen for some time I suspect.  Once we run
out of challenging things to do.... maybe a Batik (which is very very
cool IMNSHO) -> POI Serializers bridge that lets you embed Batik images
in M$ documents..  But we're not out of hard stuff to do yet..  (though
that sounds like a lot of fun :-p)... Maybe if some Batik guy comes
along and needs something to do....  Okay I'm sidetracked.

> Again, I don't want to be harsh and I want you to understand that I'm 
> all in POI's side. It's just that every reply that you give worries me 
> even more :)
> 

+1.  The reply he gave worried me too :-D.  Perhaps Ken's confused
between the Beta, Production and Development releases.  Our Beta of the
serializer had some serious issues and Ken was instrumental in resolving
those with some great test cases and some samples.  This all happened
somewhat quickly around the time he became heavily involved so it may
have looked like the turmoil was the norm when it was just that lovely
phase transition from Beta to release to first development build and
maintenance release mode.  He is correct that POI has a very quick
development cycle.  We also are very big on iterative development (so
you will see lots of patches to the API in the development build rattle
through in a short period of time).

Worry not, the "stable" build is stable, the serializer has NOT been
changed SINCE the release.  Working on the Serializer and Generator is
soooo easy due to Marc's POIFS-Serializers framework.  The changes we
did in the last week were a one time shoring up for having multiple
serializers for multiple formats and sharing serializer constructs with
the generators.  (element stuff)

ciao,

Andy


> Ciao,
> 
> -- 
> Gianugo
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
			- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org