[SHR-T] let's make shr-t happen again!

[Tim Abell <tim@timwise.co.uk>]

Hello to all potential and existing maintainers, shr-u devs, 
administrators, package maintainers, application programmers etc,

I really want to breath life back into shr-testing.

Firstly, does anyone else want to help me as a co-maintainer? Let me know!

I've written down most of my thoughts on what needs to be done and how 
it can/should be done here: 
http://www.shr-project.org/trac/wiki/ShrMaintainerHowTo Some of you have 
seen already (though I keep adding to it).

I'm finding it quite tough getting to a point of being productive, so I 
thought this would be a good point to ask the whole community for a bit 
of help.

I would like to invite people to join in a brain storm on the mailing 
list. What do you think needs to be done, how do you think we can 
practically do it? What resources are available to us and how do we 
access them? I really want to reach for the stars in terms of quality so 
I want to know what you think is the *best* approach, and then what 
compromises we might make till we outstrip android in user base and 
development power ;^D

Reply with your thoughts and ideas and I'll collate them for the wiki. 
Anything you have that will help me get moving will be greatly 
appreciated. I really want to encourage a community approach; I'm 
willing to put the effort in to make it happen all by myself, but I also 
want to make sure anyone else can take over or join in with as little 
problems as possible.

Finally and very importantly, are you a potential user of shr-testing? 
If so what do *you* want out of it? (I just want less regressions.) What 
hardware would you run it on? Would you be able to test beta versions of 
shr-t?

Thank you all reading,

Tim Abell

---

Apologies for cross-posting - I want to gain as much feedback as 
possible from all aspects of the shr community, including the upstream 
openembedded project people.