On Fri, Sep 24, 2010 at 11:43:13AM +0100, Tim Abell wrote: > Just few comments to your dump :).
> 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 "fixed in shr-u" was introduced to trace such fixes which should be interesting to shr-t maintainer, who should cherry-pick them from shr-u if they are easy (doesn't need many depending changes) or apply them with next shr-u -> shr-t merge and then mark this bug as "fixed" which would mean fixed in both. so in other words "fixed in shr-u" is something like fixed in shr-u, waiting to be fixed in shr-t too. > 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. > 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!). Great that you're still interested in shr-t maintaining.. we really need shr-t maintainer as those images are really going to be too old :). -- Martin 'JaMa' Jansa jabber: [email protected] _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
