"Andrew C. Oliver" <[EMAIL PROTECTED]> wrote: >This isn't really about that though is it, its your wounded pride. If you don't want >to have to deal with others messing with your code, by all means don't opensource it.
This is not true. I don't mind others changing "my" code. Remember, it is no longer "mine". HPSF is broken now. What I do mind is others "messing" around with some code, break it and check that mess into the CVS repository. That's not quite professional, is it? I don't mind you changing and improving code that was regarded to be mine. I do mind others breaking code it need to use (whoever wrote it). Who required you to check code with open problems into the CVS? It was you who hesitated to do that changes, not me. As I pointed out in my original posting, there was no reason to hesitate. No one would have noticed any performance degradation if the code would have been left unchanged for 5 years. You broke HPSF. This fact speaks for itself. >Personally, I hope you do create unit tests and documentation and etc, but I'm >honestly >not counting on it. You've shown very little inclination to work on POI and have >never >shown any inclination to collaborate with any of us and "when you have time" hasn't >happened >in the last 5 months I'll do that if I have a clean and working code base. >> What I'd like from you is to vote on the development priorities >> for HPSF, since Andy and I could not get to an agreement. I >> outlined my priorities in <http://jakarta.apache.org/poi/hpsf/tod >/> o.html> / >> and repeat the top four of them here: >> >> 1. Rollback Andy's changes in order to have HPSF working again. > >-1 - WORK WITH ANDY to help get HPSF working again with his changes. -1. HPSF must be fixed *immediately*. Rolling back to the old revisions can be done in an instant. Anything else would first require me to understand the general little-endian classes, consider whether they suit my need, probably adding some functionality to them - and eventually the general classes and the HPSF classes might be incompatible and thus might require a major code rewrite. What we need now is a quick action to get HPSF working again. Any other action can be taken afterwards. > >2. Complete writing the HPSF documentation. > >+100 > >3. Write up some junit tests. > >+100 > >4. Use the general POI little-endian classes (see bug 8354). > >-1 - redundant about #1 > >> Andy wants the switch to the general POI little-endian classes >> done first. This is unacceptable for me because I regard a >> correct >> functionality of HPSF plus documentation plus junit test much >> higher >> than an improved code-reuse which gives no benefit to the user >> and currently does not even work. > >This is childish. You don't like that I touched your code and don't want to >help me fix one little class, you'd rather roll back all the changes and throw >away the only substantial work done on HPSF in the last 5 months. So is HPSF >your own private little project? As explained above this is not true. We are talking about just code, nothing more. "The only substantial work done on HPSF in the last 5 months" was breaking it. >I'll only +1 rolling back my changes and freezing it until rainer "has time" if we >can move HPSF into the scratchpad until it matures. This will step it out of the >way and let others who "have time" donate something else that others can work on >without >rainers help. Currently I have time. It is up to you if you take. I am not married with HPSF. >> So please cast your votes on the priorities outlined above! >> Thanks! > >-1 - a more reasonable alternative: quit sulking and help me understand >http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hpsf/ClassID_java.html#ClassID >(scroll to the method clearly marked REWRITE ME REWRITE ME) > >Read this method before you vote! and if someone other than rainer (who donen't have >time) >wants to give me a hand in figuring that method out, that would be appreciated and >probably >make this whole argument moot! Andy, if you have problems to understand that class, you should read the HPSF documentation, especially <http://jakarta.apache.org/poi/hpsf/internals.html>. Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] K�rner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
