Am Samstag 25 September 2010, 02:18:45 schrieb Neil Jerram: > Are you asking for yourself, or for the SHR team as a whole?
I ask mostly for my self. SHR wants to be a community driven distribution. Because of that i wanted to check if my priorities of the bugs reflect the meaning of the community. If that wouldn't be the case i would have changed my priorities. But till now there are no big differences, all bugs mentions here are Milestone 1 bugs. > 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? I think the that most of the team doesn't care that much about stability of unstable (I haven't asked them). For stable images we have testing. The problem is, that there is currently no one taking care of testing. But i think that after Tim Abell has offered his help for this, we will see some new testing images soon :) I think that stabilizing unstable is impossible. Because there are too many (at least 4) moving parst and we can influence just 1 (our own software). > 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 agree a test would be nice, but for example i have no idea how automated test work. I will think about that. > 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. I was interested in the meaning of the community and you are a part of it :) Regards, Thomas _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
