On Sat, Oct 16, 2010 at 12:05:23AM +0100, Nick wrote: > Quoth Neil Jerram: > > If you mean forking from a recent shr-t release, and cherry-picking > > known-good fixes and enhancements to it conservatively - yes, that's > > exactly what I'm looking for. > > I'm sympathetic to this line, but at present I'm not sure it'll > work. The main reason being that main telephony isn't that reliable > for me (sometimes my phone appears to disconnect from GSM, with no > warning or reason, while still showing everything as fine in the > gui). This has been the main source of my issues with SHR, rather > than e.g. the SMS input bug, which as you say is fine really. I've > also had odd problems with the dialer application closing mid-call, > leaving me with no way to terminate it. > > As FSO has changed so much, and this bug (GSM issues) seems like > more the sort of "it's likely been fixed by a range of commits which > interdepend on other things" sort of issue, I think cherry-picking > fixes into the current shr-t can't result in a rock-solid phone, at > least just yet. > > I think as to general approach, you needn't worry about shr-t just > being an irregular shr-u snapshot; the only reason it has become > that recently is lack of manpower and will. With Tim marching > triumphantly on, and others hopefully following his lead, we can > definitely do better than that. > > Nick
Nick's experience with SHR sounds similar to mine. I am wondering if what we need to do is to forget about SHR-T for the moment, because SHR-U has too many bugs to allow the usual Debian approach. Instead, we perhaps need an interim version with a different name, perhaps something like SHR-F2010 (Freeze 2010)? - maybe with some icicles on the spash screen :-) Or, perhaps SHR-I2010 (Interim 2010) For me it would not matter if this included Illume1 or Illume2, FSO1 or FSO2, 2.6.29 or 2.6.32, as long as the criteria for stable telephony were the main focus. I would still like to keep an eye on speed though, so perhaps the kernel should not have debug options and QI should set the faster Glamo timings if possible. Of course, SHR-U needs to carry on as usual and I look forward to seeing the new features and speedups, but I still want at least one distro on my freerunner which I can boot into and know that it will work as a phone. Currently I am using QtMoko for this, but the QtExtended GUI is really not my cup of tea, and I hope soon that I can replace it soon with a working SHR. Ben _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
