On Saturday 26 July 2008 07:47:14 Lorn Potter wrote: > I have been told, a lot of them seem to be "I don't like the way you do > this, my way is better", or 'code clean-ups', or such that do not fix > any real bugs at all, or are specific to the Neo, and not taking into > consideration that many other (buggy) devices have to remain working.
Not quite true, some examples: - ThemedView changes and speed up's should apply to Qtopia - Various fixes to CallScreen (see our bugtracker). - If you showed the keypad, remote hang up, make a call... - Display one call as "Hold", "Connected" and "Dialing" at the same time (Menu, Buttons, Display) - many more such things... .... many more. So from the ~360 patches about 5 of them make things harder for other people. My approach: - I do clean up the incosistent usage of 1, 3, 4 spaces mixed with tabs and placing braces and #ifdef's randomly. If you write code like that you want to hide something and the reason I have to touch this code is because there is something hiding. - I create the most simple patch for the issue as possible. One patch one issue. Obviously sometimes I don't understand the consequences of my change as the whole code is so fragile. - I care little about BC, if I need to add a parameter to a method I do so, the commit messages state so though. Example: - Plain Qtopia is starting timers to guess when a call was missed, when all the data of an incoming call is present (combining RING, CRING and other notifications). This creates all funny kind of bugs as this guessing is mixed with %CPI. So Qtopia thinks the call was missed, but you get a %CPI and suddenly we report a new call. And you see "Disconnected" and "Incoming" in the callscreen. - So I decided to solely rely on %CPI information for our code. One way would have been to just remove the timers from the libraries and be happy. If I did so you could have claimed that I don't think about other devices. So as I care about the consequences for other devices where timers might be needed I added methods to make starting of timers optional. So just because some modems are worse than the TI Calypso you shouldn't punish modems that are better.... And again I fix this kind of things because it failed in reality.. not because I have fun thinking about all the possible race conditions available in the Qtopia source. - I think the approach and implementation is reasonable. If you don't think so open up and start discussing it. > > We have implemented some of his patches. I personally have done a few of > them, some after having to patch the patch. Please communicate... I get zero feedback on changes. The patch might have been seen, the patch might have been integrated... the patch might have been fixed differently is not the way to go if you want to interact with the OpenSource and FreeSoftware community. > > As well, we have been working on getting 4.4 ready to release. There are > quite a few changes in 4.4, and quite a few have to be manually > integrated and such. well, release Qtopia4.4 beta's rsync. I can see the upcoming Qt 4.5 code today as well, so what is keeping you from releasing Qtopia4.4 snapshot code today? z. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community