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.
_______________________________________________
Shr-devel mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-devel
