Sorry for taking a while to respond to this...
Tim Abell <[email protected]> writes:
>>>> If you mean forking from a recent shr-t release, and cherry-picking
>>>> known-good fixes and enhancements to it conservatively - yes, that's
>>>> exactly what I'm looking for.
>>>>
> That's a pretty succinct version of what I had in mind, yes :-)
Great!
> "To provide regular feature releases with a non-mandatory
> upgrade path from the previous shr-t, giving the users the choice to
> migrate when it suits them. Once a feature release is made, only
> carefully chosen and tested bug-fixes and security fixes will be
> provided through opkg for that release to avoid regressions and
> unexpected disruption. The inclusion of new features in shr-t from
> upstream shr-u will be done by providing complete new releases of
> shr-t, which will go through a period of beta testing before official
> release."
That sounds good to me.
> I think I still have a lot of practical problems to solve to get
> anywhere with this, but hey, how hard can it be? (don't answer that!)
>
> One such issue is what to do with backported patches. At the moment
> I'm thinking of putting actual patches into the openembedded part of
> the shr-t git tree, as I think there's already a patch handling
> mechanism there. This would allow us to apply just specific patches to
> an older upstream package.
Yes, I believe that's all correct.
> One last thought while I'm rambling. I'm increasingly of the opinion
> that one of the key factors in the success of the mythical shr-t will
> be the effectiveness of tracking bugs in the different versions. I
> will at some point give further thought to how trac fits in with that
> but I'm not sure at the moment. I might look into launchpad as it
> seems to have excellent tracking of bugs across multiple versions /
> distros etc.
I'd be surprised if the existing SHR trac couldn't handle this too. I
agree with your point about a bug tracker being important.
> Thank you all for your input to this thread, it is very much
> appreciated, and gives me a real sense that there really is a vibrant
> and enthusiastic community out there.
Subject to limited time, I'm happy to help however I can.
I think the first practicality for us to decide would be: where to start
from? Do you have any candidates for that? From my point of view,
d9df9d9aee12d719dc306063c32ce8cdc6821789 (Time Stamp: Mon, 03 May 2010
11:59:06 +0200) is one good option, since that's the SHR-T that I've had
on my phone for a while, and I'm pretty happy with it. But I think
there's been at least one more SHR-T release since that, so maybe you
(or others) would prefer to start from one of those more recent
releases?
Regards,
Neil
_______________________________________________
Shr-User mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-user
