Thomas Zimmermann <[email protected]> writes: > 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?
Are you asking for yourself, or for the SHR team as a whole? It seems a bit strange to ask, because - if it isn't already obvious to you which are the most serious bugs, I'm sure you will get conflicting answers from the people on this list - given a pool of bugs that are roughly equally serious, I think it would make sense for you and your team colleagues to pick off whichever ones you personally feel most comfortable about tackling. Now it may be that that strategy may leave a couple of hard bugs that no one in the current team feels like taking on. But that's OK, because by clearing up the other ones you will have clarified the overall picture, and you'll motivate someone really hardcore to come in and tackle those last remaining bugs. Also I'd like to mention testing (again, having recently raised it somewhat inappropriately in another thread). For me at the moment, arguably the #1 bug is that it seems to happen too frequently that things that were working are randomly broken. For example, the mailing list at the moment has discussions about GPS and GPRS having broken, whereas previously they were working. Yeah, I know it's called "unstable", but do you want SHR to stay unstable forever? It doesn't have to be like that; I think you just need to start building up a regression test suite. (I hope I'm not being unfair here by ignoring test suites that you already have. As an example, I just took a look at http://git.shr-project.org/git/?p=phonefsod.git;a=summary, and I don't see anything in the tree there that looks like a test suite.) So, in summary, I'd suggest that - as a team, you decide from now on to write a regression test for everything that you fix, and put in place whatever basic infrastructure is needed for that - after that, you each work on whichever bug you feel most effective - based on a combination of your ability and how important it seems. I hope this comes across as trying to be constructive (and not condescending). You guys have already achieved wonders to get SHR to where it is today. If only it's possible to fix the few remaining important issues, without breaking anything else, I think you're very close to completing a reliable and exciting daily phone system. Regards, Neil _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
