On Mon, Feb 14, 2011 at 7:46 PM, wrote: > http://www.codfusion.com/blog/post.cfm/so-there-s-this-story-about-a-frog-in-boiling-water
So you claim the following problems: > - a rise in serious bugs and security flaws like the FCKeditor hack The criteria for meriting a security patch have been pretty constant over the years: remote exploitability with data disclosure or crash potential. So I would say that the list at http://www.adobe.com/support/security/#coldfusion proves you wrong. > - slower response times to those bugs and flaws fixed (it takes a full day > for the staff in India to even see the problem) Do you send your bugs to a product manager, the product manager gets cracking and writes a patch, and sends that back to you? I guess we just have different experiences here. My experience is that if I sent a technical issue to a non-engineer he will just forward it to an engineer X hours later, in effect introducing an X hour delay. > - increasingly complex patches and updates. Patches used to be a simple > dropping of a jar file. Now when a patch comes out, people spend days having > to manually patch all their CF servers. I don't see this as a significant change. In the total workflow that starts with testing the patch in your own environment, scheduling downtime, making backups, rolling out the patch, validating that the rollout went right, whether you copy one file or a complete WEB-INF folder is totally insignificant. (Though I would still love to see a Maven repository so I can just update the version on my dependency.) > - odd language additions - cfscript has plenty of odd things now because the > staff in India is inexperience in language development. In a language with a 1-based index, where a query resultset is a map of columns instead of a collection of rows, where in nested cfoutputs the outer cfoutput looses its cursor position, where variables inside a UDF mix freely with the variables outside it, where a UUID is a 35-byte string instead of a 36-byte string, you are seriously complaining about what was recently added to cfscript? Next, the points you want people to agree with: > 1. The Adobe ColdFusion project management should be based in North America > and have a long history in using the products. This provides the critical > link between the customers who use ColdFusion and the engineering staff. Having product management in North America, a small land area with 5 timezones of water to the east and west, is just too inconvenient. For the type of "quick patch turnaround" you are clamoring about product managers are irrelevant anyway and the dedicated sales people can pick up the slack for the rest. As for contact between customers and the engineering staff I have a story. I deliver training in India a few times a year and most of those are for Indian companies doing contract work for US companies (those 'critical clients' you mention). I once was in Bangalore for a LiveCycle training when I went to a Flex event and was approached by some people from the Adobe ColdFusion team who recognized me. I think the engineering team doesn't need a product manager for that critical link. > 2. The trouble ticket system needs to be finally addressed. It needs to be > switched to JIRA and properly monitored. We don't need a repeat of the > FCKEditor mess and its aftermath. Sure. But what does this have to do with fckeditor? IIRC it was PSIRT that dropped the ball, not the bugtracker. And what does this have to do with a product manager? Are you suggesting that monitoring a bug tracker is a job for a product manager? > 3. The ColdFusion ACPs should be treated as a group of caretakers for > Coldfusion and consulted in any major changes in the server or builder. These > are many of your core customers actually, you should already be doing this. > Plus, they should be completely free to voice their opinions. I think ACPs have a pretty good idea of where ColdFusion is going. With that in mind I can't think of a single major change where ACPs were merely consulted. For every major change the ACPs were the ones asking for it. As for the frreedom to voice my opinion, my main concern is not to piss of the team so they don't want to drink beer with me anymore. I consider that a low probability event regardless of what I say :) > 4. A language committee needs to be set up to properly evolve the CFML > language. These people don't have to be from the competing CFML engines, but > they should be experienced in computer language development. Some ACPs may > qualify for this, but there are many people in academia, etc. that can be > called on to help. I don't really see the point. A language consists of 2 parts: syntax and functionality. I think the syntax is pretty much decided for the next few years. We have CFML, we have cfscript and I don't see any major overhaul happening where we start making CFML XML compliant or something. A focus more on core language design principles for the cfscript push in CF 9 would have been nice, but that ship has sailed (without any problems that are insurmountable IMHO). That leaves language changes due to functionality additions. The choice what functionality will be added is a business decision and we don't need a committee to decide whether a new tag will be named cflivecycle or cflcworkspce or cfpdfservice. (And for that sort of design you won't be able to interest any serious academics either.) I guess I could just have written that I don't see what the big deal is. Jochem -- Jochem van Dieten http://jochem.vandieten.net/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342309 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
