[cut moaning]
> -Not trying to defend ourselves or anything, but keep in mind that SHR 
> is not Debian with >1000 active devs. We derive from a highly unstable 
> distribution (OpenEmbedded development tree), and much of that is 
> outside our control. So stuff changing and disappearing might not always 
> be our fault, we cannot check every change that goes into OpenEmbedded 
> and we don't have the rights to veto those that we don't like.
I get your point, but what about deriving from stable branch of OE? Is
it out of consideration?

> -2nd, SHR did chose to live on the technology edge and using highly 
> experimental stuff like EFL/elementary and whatnot, rather than sticking 
> to good old gtk/qt. (and that choice can be questioned, of course). This 
> means that functionality often breaks with each upgrade or functionality 
> is simply not yet implemented.
Living on the bleeding edge has many virtues, especially for developing
new technologies, but in the end these technologies are intended for end
users. Aren't they? IMHO SHR lives long enough to release stable branch
with less features, but with basics working out of the box. SHR is
really mature enough. Just grab one of testing releases from last month
or two, which behaves best and name it stable. That is a good start for
me.

> -3rd, much of our functionality comes from 3rd party apps and we are at 
> their whim: eg if mokonnect doesn't work or were not developed anymore, 
> there is little the SHR devs can do about it. Similar with our 
> technology backend: FSO. Currently there is only 1 guy working (unpaid!) 
Who is that?

> -4th There is a total of about 5-6 people active in SHR 
> development/maintenance, none of them paid for it.
> - mrmoku, Tasn are busy coding the phone app frontend
> - dos is doing shr-settings, opimd and graphical stuff
> - myself looking at shr-testing, fixing minor issues and annoying people :)
> - Jama, heinerdvm helping out with distro maintenance
well, take a look at QtMoko. If I am informed well, it is developed by
one guy, Radek Polak. Considering this, it is obvious that QtMoko
progress is slow, but it is quite stable distro. Maybe because it
derives from stable branch?

> You see that there are very few people employed in our QA department, 
> and our distro maintenance department is pretty small too (as people 
> need to code apps). I am not saying "patches welcome", but if there were 
> more people active, things were a lot easier...
My answer here would be like in previous paragraph.

[cut]
> I am tempted to just call the existing snapshot SHR-stable :).
As i wrote few paragraphs earlier - it is quite good start.
Additionally, if i was some application developer, i would like to have
a stable development environment.
> Let me know about things that don't work in shr-testing (and I don't 
> mean feature requests with that, those go to shr-unstable :-))
I need at least a week for this. To flash back SHR (nice, now I felt
like addicted ;) ) and use it for some time.
My proposition is this: on 14th CU I will put an entry that SHR-testing
is waiting for last bug reports before renaming it to Stable. Maybe this
way we will encourage some additional men-power for testing and bug
reporting. What about that?

-- 
Patryk "LeadMan" Benderz
Linux Registered User #377521
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments


Email secured by Check Point
_______________________________________________
Shr-devel mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-devel

Reply via email to