Hello, I like to see that SHR testing/stable finally got new maintainer!
I agree with your testing and releasing plan, but please use proper naming conventions to prevent users confusion. Use SHR-t branch for beta testing and stabilising. Don't be afraid of releasing SHR stable when the beta testing (SHR-t) branch is stable. Best regards, Martix 2010/10/19 Tim Abell <[email protected]>: > > Ben Thompson wrote: >> >> 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. >>>> > > That's a pretty succinct version of what I had in mind, yes :-) >>> >>> 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) >> >> > > I see where you are both coming from. I'm beginning to formulate the view > that I need to somewhat limit the documented scope of what I'm trying to > achieve with shr-t. > > Rather than trying to be all things to all people, and to promise a version > that is all round better than any shr-u with the mythical reliable "phone" > bit, I think I shall make the clearly stated ambition of shr-t something > like: > > "To provide regular feature releases with a non-mandatory upgrade path > from the previous shr-t, giving the users the choice to migrate when it > suits them. Once a feature release is made, only carefully chosen and tested > bug-fixes and security fixes will be provided through opkg for that release > to avoid regressions and unexpected disruption. The inclusion of new > features in shr-t from upstream shr-u will be done by providing complete new > releases of shr-t, which will go through a period of beta testing before > official release." > > The upshot of this will be that shr-t will not be "better" than shr-u per > se, but will instead attempt to provide stability for those who do not wish > to take the bumpy ride of bleeding edge updates. I agree that it isn't > feasible to avoid some of the more complicated and nasty bugs that show up > from time to time in shr, but I don't think that should stop us trying to > provide something that is at least a bit more "stable" in some respects than > the current shr-u (where an opkg upgrade is a risky business and requires a > visit to irc to see if anything is known to be broken today). > > To use a (mythical) gsm bug as an example: > > * If there were to be a bug in shr-u that has always been there, then it > would also exist in all shr-t versions (inevitably). If that bug is serious > (such as gsm failures), and a fix becomes available in shr-u, then attempts > will be made to apply / backport that fix to the currently supported > versions of shr-t. This will be done by applying the smallest possible diff > to shr-t. If it is impossible to apply a minimal diff to shr-t (say the fix > requires a major rewrite), then the fix will not be available till the next > feature release of shr-t. > > * If there was a regression introduced to shr-u, either as part of an > ongoing refactor, or through a mistake, then testing of pre-release versions > of shr-t and any pending patches for released versions of shr-t should (in > theory at least) prevent the regression making its way into supported > versions of shr-t. When the next feature release of shr-t is due, such > regressions may be included in the new beta version of shr-t, but would be > tracked and expected to be fixed in shr-t before the new shr-t release was > considered/pronounced ready for non-beta users. > > I think at some point I would like to see the work in shr-u to be guided to > an extent by the release schedule of shr-t, with major reworks occurring > after each shr-t release, and polishing and bugfixing happening in the lead > up to a freeze of features going into shr-t. This is I think how it happens > in the ubuntu and debian world, and I think this is a fine thing. I'm not > however going to try to persuade the shr-u devs to change anything at the > moment as until shr-t has proved its worth I think it's more important that > the current rapid rate of progress and groundbreaking work is kept up. >> >> 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. >> > > For now I'll probably avoid fiddling with such settings / optimisations to > reduce the risk of shr-t being even less stable than shr-u ;-) But in > principle I agree that this is a good idea (in the same way that ubuntu only > enable automatic bug reporting in pre-release versions). >> >> 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 >> > > I think I still have a lot of practical problems to solve to get anywhere > with this, but hey, how hard can it be? (don't answer that!) > > One such issue is what to do with backported patches. At the moment I'm > thinking of putting actual patches into the openembedded part of the shr-t > git tree, as I think there's already a patch handling mechanism there. This > would allow us to apply just specific patches to an older upstream package. > > One last thought while I'm rambling. I'm increasingly of the opinion that > one of the key factors in the success of the mythical shr-t will be the > effectiveness of tracking bugs in the different versions. I will at some > point give further thought to how trac fits in with that but I'm not sure at > the moment. I might look into launchpad as it seems to have excellent > tracking of bugs across multiple versions / distros etc. > > I think that's quite enough typing for one evening. I'll keep adding to the > wiki as I pull this all together in my head. > > Thank you all for your input to this thread, it is very much appreciated, > and gives me a real sense that there really is a vibrant and enthusiastic > community out there. > > Yours > > Tim Abell > _______________________________________________ > Shr-User mailing list > [email protected] > http://lists.shr-project.org/mailman/listinfo/shr-user > _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
