This is great discussion! I always appreciate being part of this global community!
Larry wrote: "so I would like to acknowledge that your programming skills have come a long way since you first started working on OJ (in 2005?). " Thanks for the complement. I actually started in around 2004, and Java/OpenJUMP was my first attempt at any type of programming. I had no idea how far this little adventure would take me. Still, I recognize that I am just a "hobby programmer" and have much to learn from other, more highly-skilled, programmers. Actually, I learn a great deal from Jon and Martin, trough the design of JUMP, even though they aren't actively involved in the project. Those guys are magicians in my modest opinion. :] Larry wrote: "For me, there are only a few reasons for changing code in a legacy project: to fix a bug, or to add needed functionality. On very rare occasions, it may be necessary to modify the core architecture such as was done with Threads, the rendering system, or Paul's recent Open dialog changes. Ideally, these changes should be done by a programmer with experience in this area. Even so, they almost always turn out to have unintended consequences. I guess I don't like the precedent of randomly modifying the core Classes just because they don't seem optimal. I could do that too, but I resist the temptation because I don't know where it would end. In fact I have made dozens of experimental modifications to core classes that I never proposed to OJ because I can't prove that they actually improve speed, reliability, or memory utilization, or that anyone would ever use them. So I don't like to support core Class changes, but exceptions should be made if someone feels strongly about them. So do you feel strongly that these changes will improve reliability and be worth the possible unintended side effects? If the answer is yes, then I think we owe it to you to support them." I think there are two camps emerging in this thread. In the first camp are programmers that believe you should only tinker with something that works when absolutely necessary, and in the second camp are guys like me that are always looking for small ways to improve things. There are certainly advantages and disadvantages to each approach, and based on past experiences I think it unlikely we will get everyone to agree on a common policy. However, I think there is a reasonable solution: I'll keep all of my changes in my own fork. I'll regularly present these changes to the OpenJUMP programming community. I'll clearly identify those changes that I think are necessary to avoid bugs to to enable a critical new function in the program. This type of change will be distinguished from changes which are cosmetic or very minor. Then we can let the changes be approved and adopted by the group on there own merit. (I'll try not to get my feelings hurt when something doesn't get in.) :] Let's look at my TaskFrame/Workbench Context changes as an example: Critical Changes: Call CursorTool.cancelGesture method when closing a TaskFrame. Remove TaskFrame.setTask method and modify WorkbenchContext.addTaskFrame method to no longer use ComponentFactory. Cosmetic Changes: Group all public, protected, and private methods together in class file. Implement InternalFrameListener instead of using hidden InternalFrameAdapter class. Add isAClone member variable, setIsAClone public method. Add Javadoc comments for all public methods. So, what do we think of committing my critical changes in this case? Would we be interested in any of the cosmetic changes? I want to point out that if we take a more assertive stance on unit testing JUMP cosmetic changes to the core would be less of a risk...Maybe I'll start working on some unit tasks for key classes in the core. The Sunburned Surveyor P.S. - Stefan wrote: "there is no special treatment for you. I hope to respond with a second email later. However, in short I may add that Larry hits the nail also from my perspective." Please forgive me for that comment Stefan. I've been moving into my new house and life is still a little crazy. I was quite cranky when I wrote that and it sounded more hostile than I intended. Your a great asset to OpenJUMP and you are write about the group coming to a consensus on the policy that was making my hair stand up. On Sun, Jul 6, 2008 at 2:22 PM, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > only on this: > >> Stefan wrote: "So commit rules will be >> more strict in terms of agreement and outlining the absolutely necessity >> of those changes and the expected problems with backwards compatibility >> [e.g plugins]. I may refer here to emails by Sascha Teichmann. >> Up to now there is still the wise saying: "never touch a running system." " >> >> As long as everyone else has to play by the same rules. If I'm getting >> special treatment I should at least know the reason. (I'll gladly >> accept suggestions or recommendations that deal with technical issues >> in my source code.) > > there is no special treatment for you. > But I believe there is also a misunderstanding: I/we aggreed on the > rules outlined above (only) for the OpenJUMP "core". Here, "core" is > meant rather in terms of core classes (e.g. stuff in > com.vividsolutions... that are not plugins and config files and so on) > and not the openjump sources in general (right now core also includes > Paul's additions for the framework in org.openjump. - but only those). > TaskFrame and WorkbecnhContext are such core classes. Changes here are > "restricted" from my point of view - which may not necessarily hold for > "adding" new member functions or fields. However, both need to be > discussed in the group. > > I hope to respond with a second email later. However, in short I may add > that Larry hits the nail also from my perspective. > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
