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
