Sorry guys this got munched by my ISPs defective email server. >>>"Andrew C. Oliver" <acoliver <at> apache.org> 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? >> >> > >You did, I did it to collaborate in finishing the work. Because no one understands >this >underdocumented piece, no one could work on it but you. Catch-22. > >If I kept the code locally, no one could help finish this right? right. > > > >>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. >> >> > >Yup. I'm the only one who's worked on it recently. Lets assume for just a second >that >I know a little bit about working on these file formats. Lets assume I'm a slighly >above >average as far as abillity to understand the sources. So turn >this around, I tend to be reasonably conservative on what is checked in. I tend to >be >more able to understand various low level sources in the project. However, I was >unable to >understand this source, I felt strongly that the work needed to be done. I intend to >revist this for further refactoring and documentation, but I needed a hand with this >part first >from the only person who understands it. What does that say? humm? > >It sounds like something good is coming out of this anyhow, my mistake was not >getting together >with folks who care about the project and seeing if we could figure it out. It looks >like >Ryan and Glen will pick up for your slack. It will be less efficient than if you >were willing >to help, but we'll get there. As always, thanks guys! Your increadible efforts >on the project are always appreciated! You guys rock! > >/>>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. >> >> > >Well rainer, you don't want to help getting there with one method of one class. So >we go back to the issue whether you want to do this collaboratively or if its your >pet project? Help me fix this one tiny little underdocumented method, and lets move >on. > >You're not willing, but it sounds like with Ryan and Glen's help we may be able to >get this >done anyhow. so this is moot to me. > >/>>> / >/>>> 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. >> >> > >That is a rediculous estimate. What you're doing is parsing little endian values, >writing little endian values. These may be signed or unsigned. Anyone else pipe up >if >this sounds like a major ordeal, perhaps I'm dull, but this sound pretty dern generic. > > > >>What we need now is a quick action to get HPSF working again. Any >>other action can be taken afterwards. >> >> > >No. I disagree. We need to make HPSF into a real POI component that others can >collaboratively work on, that fits in with the common facillities of the project, that >meets community standards... Otherwise it needs to go in the scratchpad. If we move >it >to the scratchpad, you can do whatever you like with it. Maybe one day you'll have >enough >time to achieve this alone. > >But at the moment with Ryan and Glen's help I'm confident we can fix this single >method and >get this up and running so HPSF works. From there if you feel that is not a clean >enough base >to work with then I don't know what to say. > >/>>> 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. >> >> > >Rainer, look at the list and the feedback you're getting. No one understands why >fixing >this method is such a big deal (including me), no one unstands (including me) why >using the >same classes that serve 3 other POI apis don't serve this one. > >Yes its broken, help fix it. 1 method. est 30 minutes for someone who understands >what it does. >But between the three volunteers, (which is awesome), I'm confident we can figure >this out. > >/>>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. >> >> > >Rainer, I barely care currently. Make your choice, work with us or not. Surely you >see >that the little effort you've put forth does not make a divorce that serious of a >threat. >I hope it doesn't come to that, but in the end I have to respect a man of his word. > >Rewriting HPSF versus having this argument with you everytime I want to get anything >done (my >next steps were to add unit tests, then docs, then write capability) in this area and >having >code that I can't understand or modify (which do note I don't have this complaint >with HDF, any part of >HSSF, POIFS, etc), and the "you're way or the highway" approach... you don't want to >work with >me but you "don't have time" to do it yourself... Its a tough decision if you put it >that way, the >cost benefit analysis is not back yet on this issue. > >I continue to hope it doesn't come to that, but I'm not going to bend over undo my >work just >because you're upset and don't feel like helping me fix this method or at least >helping me >understand WTF it does. > >/>> 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>. ><http://jakarta.apache.org/poi/hpsf/internals.html%3E.> >> >> > >you mean this one: > >ClassID > > > >0x00000000000000000000000000000000 > > > >Most property set streams have this value but this is not required. > > > > >how does that help me? > >-Andy > > > >
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
