How can anything related to a such a small little script library like prototype and scriptaculous be viewed as a maintenance nightmare? I mean we're talking about 6, 7 files tops, none of which are any larger than a few hundred lines. So it takes all of 30 minutes, maybe an hour, to incorporate the changes I need/want when a new release comes out, or someone posts a nice addition that I want for my project. Hardly a nightmare.
We are not talking about massive frameworks here, not by any stretch of the imagination. Anyway, not meaning to start a war. Thank you for putting your comments into context for me. I still don't think they offered anyone any constructive help. > Releasing code that changes "public" components > (prototype / scriptaculous) without the intention of merging those > changes back into the public component is doing everyone who adopts > those changes a disservice Releasing code that offers new functionality at a cost of $0 to anyone who wants to use it is doing everyone a HUGE service, no matter what way you want to look at it. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Ross Sent: Friday, February 17, 2006 10:03 AM To: rails-spinoffs@lists.rubyonrails.org Subject: [Rails-spinoffs] Re: RE: Sortable Tree Addition [PATCH] Ryan Gahl wrote: > Anyway, my point was, Sammi offered a great contribution and was replied > to with "...and did you just change the indentation for the fun of it"? That wasn't in relation to my tabs vs spaces critique. It was a changed line that had no functional differences. > I change the indentation in my stuff to tabs (which in all my experience > have worked across editors), and I also change the bracket styles from > > function() { > } > > To... > > function() > { > } And in the process have created for yourself a maintenance nightmare if you ever intend to upgrade the components that you made "preference changes" to. (There are, actually a few outcomes of upgrading a public component after you've made changes to it. You can replace the component outright, at which point, your changes get lost, so why make the changes in the first place? You can attempt to merge the changes, but you can't do it using the utilities available (such as diff and patch), which is a maintenance problem because it's manual and error prone. You can choose not to upgrade, at which point, you're losing out on the useful functionality that others are providing through the proper means.) In any case, you made that decision for yourself; don't force it on others if you release changes to a public component that you think others would find useful. > ...Those are such matters of preference I think there is no point > bringing that up in reply to someone's functional contributions. That > was my real point, just sticking up for Sammi in those matters of > preference. I commented on this code with an eye towards inclusion. It was a /technical/ review of the bits that I cared about (prototype). That means honoring the coding style of the existing code base and following their conventions. Releasing code that changes "public" components (prototype / scriptaculous) without the intention of merging those changes back into the public component is doing everyone who adopts those changes a disservice. Now, you could argue that the people who adopt said changes are taking this burden upon themselves, but I would in turn argue that having useful changes merged back into the public component is more efficient for everyone. Yes, it's a cool new feature, but it's also a maintenance problem. > It just makes someone feel like not wanting to contribute further when > they are picked at for such meaningless stuff. And big deal about his > licensing line... we all know this stuff is all free for anyone who > wants it. No one here (or very very FEW if any) of us are lawyers... > give the guy a break and reply constructively to the functionality, not > nit-picking... My goal was not to discourage contributions. It was to provide a technical review. The result of which is that /none/ of the changes made to prototype.js needed to have been made. I provided examples of the alternative code that prototype is already providing. I hope that provides the context you need to understand my comments. Todd -- Posted via http://www.ruby-forum.com/. _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs The information transmitted in this electronic mail is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
