bluegaspode;525448 Wrote: > I think its not fair to claim your patch was the best of all and > everything done later was to the worse. > Your change was a BIG step towards a very good solution on the given > architecture, but also with Bens additional changes to your patch we > have a much more stable alarm situation in 7.4.2. Maybe even more stable > than your patch ? Who knows ? >
You are welcome to your opinion, of course. If anyone has the desire, time, and compunction to look back at the extensive conversation thread that took place in the developers forum then it's there for the perusing. Honestly, your comments are a pointed illustration as to why it makes little sense to keep working toward stability. Your 95% estimate of my changes that were incorporated is a poor one. My architecture was indeed used, but far more than 5% of the changes that I made were discarded. The devil is in the details, and the details were not respected properly when important pieces were discarded. This is particularly true in the context of how the client/server architecture used is/was unintuitive and more, rather than less, pedantic code is/was clearly a necessity to track and defend against unexpected behaviors. You are wrong, by the way, about the changes made to my modifications having increased stability. They did not, as evidenced by the problems that remain in 7.4.2. I warned specifically against sacrificing some of the state tracking I had added, yet my warnings went unheeded. It's true that you weren't convinced after much debate, though, so perhaps you still believe the right course was pursued. I admit that it's a bit offensive, though, when you say glibly that perhaps the changes I recommended retaining weren't up to the standards of the now disseminated 7.4.2 code - which is clearly still unstable. It would make sense for you to defend the now released 7.4.2 code, despite its continued instability, I suppose, since perhaps you feel the need to take some measure of responsibility for not being convinced of a number of the since discarded stability measures I lobbied for. bluegaspode;525448 Wrote: > > Without logs for the current minor hickups noone is able to tell, who > is to blame. Remaining parts from the 7.4.1 code-base? Your original > patch ? Bens later changes ? > I attempted to get the log after the malfunction occurred (while I should have been headed off to work). Unfortunately, it had been quickly overwritten and was lost. I've also suggested that logging be enhanced to prevent this type of situation in the past, if you recall. bluegaspode;525448 Wrote: > > To make at least one logitech developer feel very comfortable with the > current code :) > It wouldn't make sense to take your changes as a 1:1 copy to make your > debugging now easier ... its far more important that logitech feels > comfortable with the code and is able to understand its current ideas on > the long run. > No one suggested a 1:1 copy of my work. The code I'm alluding to that was unwisely discarded consisted of specific state information that was tracked to enhance both stability and post-mortem analysis. Nor did I ever state or imply that 'everything after [my changes] was to the worse'. I'm afraid you're putting words in my mouth that I don't appreciate here... Ok, so now Logitech is ostensibly more comfortable based upon your commentary (not an unreasonable point). Are they now working on these new issues, whether making logging more useful to facilitate log feedback from customers by preventing log overwrites or by continuing to test alarms in 7.4.2? Has that development comfort translated into alarm robustness? I'm not going to get further into a personal defense of my work, nor of my history and expertise in embedded product development. Suffice it to say that I am not (and was not) guessing when it came to working toward alarm stability. Logitech as an organization has a lot to learn about both embedded development and client/server architecture... It's too bad, really, because I truly believe the Radio could be huge. bluegaspode;525448 Wrote: > > That being said - lets at least spend time in creating the appropiate > logs for the current 'backup alarm even though the stream seems to be > available' problem. Noone asks for or expects further debugging. If the logs were there then that would be possible... -- Marc ------------------------------------------------------------------------ Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=75541 _______________________________________________ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
