These are quite high on my list of annoyances:
* infuriating default lock/dim times
http://trac.shr-project.org/trac/ticket/889
* dim settings not persisted across reboot
http://trac.shr-project.org/trac/ticket/958
These annoy me every time I reboot (whenever I switch from shr-u on
internal flash to shr-t on sd and back).
I've got more niggles noted down but I need to tidy them up and make
sure they are filed in trac. I have a bit of a perverse interest in bug
herding myself so may spend time helping tidy stuff up in trac. Let me
know if I'm being a positive impact or if I'm annoying anyone!
---
I've been thinking about how to manage bugs that occur in one or more
versions of shr, as I'm thinking about how shr-t should be run from here on.
Given that we currently just have shr-u and shr-t, if a bug exists in
both, how should it be categorized in trac? The version field only
supports marking a single version. I see we have "fixed in shr-u" in the
resolutions, which I guess implies not in shr-t, but some bugs might
never show in shr-t so if a bug is marked as version shr-u it will be
hard to tell (for the shr-t maintainer) if the issue affects shr-t or
not. If it is marked as shr-t it might not be clear if it still affects
shr-u. I don't really have an answer but it's something that's been
bothering me. It might be worth having a look at how
https://bugs.launchpad.net/ manages bugs against the many currently
supported versions of ubuntu. Would it be possible to configure trac to
have multiple "affects x version of shr" and "fixed in x version of shr"
fields or similar, so that we can track exactly which versions of shr
are currently affected and which still require attention? (This is of
particular interest to me as a potential shr-t maintainer as I would
need to know which bugs affect shr-t specifically and which have fixes
available in shr-u, as well as what the impact is etc).
Incidentally I'd also like to see shr move away from pulling new
features as a drip feed directly into shr-t and instead move to the
debian/ubuntu model where at regular(ish) intervals a snapshot of shr-u
is made into the beta of the next shr-t, and once that shr-t becomes
semi-stable and officially "released" the old shr-t just moves down one
but continues to be maintained for a while. I suggest we attempt to
mimic ubuntu's schedule https://wiki.ubuntu.com/Releases as I think
fixed dates work well, and the ubuntu people are trying to persuade all
the distros to rally around the same dates (so that the kernel, kde,
firefox etc all produce stable/unstable at the right moments for
integration into distro releases, which I think is very sensible). If
no-one objects I'll document this plan in the page I added to the wiki
http://www.shr-project.org/trac/wiki/ShrMaintainerHowTo and attempt to
run the shr-t releases myself (though I am interested in the way debian
appoints maintainer responsibility etc even if I haven't got my head
round it yet!).
Apologies for brain dump!
Yours
Tim Abell
Thomas Zimmermann wrote:
I sorted the bugs in SHR trac into the several milestones after i was away for
some months.
But now i would be interested in: Which SHR-unstable bugs are the most
annoying ones for you?
I tried the 21. lite image and i would say that are the following one:
* Shutdown with quickstettings needs 2 minutes, because of a timeout.
* Connecting to GPRS doesn't work because fsogsmd crashes.
* Next button in first start wizzard doesn't work, so it's hard to get stared.
But what do you think?
Regards
Thomas
_______________________________________________
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
