Am Freitag 24 September 2010, 12:58:33 schrieb Martin Jansa: > On Fri, Sep 24, 2010 at 11:43:13AM +0100, Tim Abell wrote: > > 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 > > yup, that's why there is newer shr-t I've built long ago > http://build.shr-project.org/tests/shr-testing/ > but never merged to normal feed in > http://build.shr-project.org/shr-testing/ > because request for testing didn't show clearly if it's worth it and if > somebody is interested in this upgrade. And because I'm not using shr-t > myself at all, I'm not going to spend much time testing it.. > > but for next shr-u -> shr-t merge I would like to see something like > shr-u was just before switch to 2.6.32, because I see lots of complains > about uSD instability etc after we switched.. so it could be good > next-shr-t base.
I think that the way, to make an shr-t, we used till won't work. For a real stable shr-t we have to fork the shr-apps and fso. Because these are under constant developement and introduce new bugs all the time. That way we can't get a bug free version... For the next shr-t i would sugest we wait for a working illume, and then build an rc1 from current shr-u with the 2.6.29 kernel. Then create a new version in trac: shr-testing-01.2010-rc1 And then backport all fixes to this version. It's a lot of work, but i think it's the only working one... I think i would help with this too. _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
