Hello all,
I am happy that SHR in coming again on the front. I use my FR as my
daily phone, for professional purpose. It is out of question to use SHR-U.
I need a stable SHR, with less bugs as possible. I am quite happy whith
the existing one. My main regret is that some annoying bugs are well
known, but not corrected.
SHR-T is the more important version of SHR, because it is the one used
by "new user". If their experience is bad, they conclude that SHR is a
shit, and claim it on internet
I am only a user, not a dev. So my opinion is just a user point of view.
For me , if a development cycle of SHR-T have to be done, it could be:
1) Identifying critical functions that must be bug-free (phone, contact,
messages, phone-log, GPS, ....)
2) Making a freeze of SHR-U at a time it works without critical bug
3) create a new branch, independent of SHR-U, and let SHR-U follow its
own race of improvement
4)identify and fix the bugs in "critical functions" identified in 1)
5) then the level of bug reach an acceptable level (ideally 0), release
an SHR-T, but only when it is ready, not because its time!
6) correcting all the remaining bugs in SHR-T (very important)
The cycle of freeze could be every 6 months, or more, if SHR-U have to
many bugs to be frozen.
Le 13/10/2010 23:46, Tim Abell a écrit :
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-User mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-user
_______________________________________________
Shr-User mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-user
