as a debian user, I fully agree with your proposal.
and I can add: before switching to a "new" SHR-T (new freeze of SHR-U),
you can put the "old" SHR-T in a separate location and called it
"SHR-Stable" ;)
Le 19/10/2010 01:27, Tim Abell a écrit :
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
