[oi-dev] sigcpp issue

[Nikola M.]

On 10/ 9/13 05:49 PM, Alexander Pyhalov wrote:
> As I understand it, /usr/g++/ libraries is a temporary solution which 
> allows us to avoid breaking Sun CC-compiled programs. When we can 
> rebuild everything with GCC, I think it's a good idea to rename 
> libraries to original names and move back to /usr.
What about all those apps that could not ever be compiled by us 
(applications that people clearly expect to continue working in 
Openindiana/illumos distro and are binary-only).
We need also workaround for this (if it is a whole sub-project to create 
this long-term workaround, be it)
>
> So, there are two reasons: insufficient testing and the main one - 
> nobody cares.
I think that by just looking on few reactions on a bit more stable media 
but IRC channel,
(Udo Grabowski) and mine, and possibly others, that actually think of 
what people are using in the wild,
that noone makes good interaction and coordination and research of user 
needs,
before making changes that break compatibility with every Studio 
compiled Opensolaris and Solaris10 app (and that is everything except 
packages in OI).
>
> As for some reasonable policies - if someone could propose them, I'd 
> be glad to hear.
I would like to propose several things:
- User registration base (default icon on desktop for registration and 
reporting bugs and documentation, default text document in home user dir 
with similar contents, that would explain a contact with people and link 
them and subscribe them to pools , webinars, manuals, project info, 
announcements and calls for inclusion in varies areas of a project. 
(includes opening of openindiana-users mailing list with subscribing all 
current openindiana-discuss users to it for a start)
- Manage levels of user willingness to contribute, and abilities one 
posess to do that
- Having starting documentation and steer new users toward learning and 
education prerequisites toward contribution in various parts of the 
distribution (mentoring)
- Having clear explanation on Wiki and web site about administrative 
roles within OI and sub-projects that new people could contact and 
sub-coordinate with to make new projects alive
- Having web site changes that more easily shortly explain what project 
is about and how to do basic functions with it (Better linking bug 
report links and so on) and explaing how it is of great benefit to 
report bugs and contribute code.
   And have some explanatiion of process of distribution life cycle and 
path from changes, to testing and to the product.
- Checking interdependency of projects and requirements between them
- Making testing process that includes volounteers from step 1. and 
steer them via users mailing list
- Harwest information from /dev and /hipster to see what packages are 
actually used and installed the most , what people search the most for 
in packages and volounterely on user permission, have application to 
scan and report other packages and uses types that are of interest for 
the OI usage info.
Also use download and fresh installation statistics in having 
geographical information of users
(comes to the topic of rejuvenating local user groups)
- Promptly fix packagemeneger GUI, to work again, so users can actually 
do tasks of searching packages.
- Look for sponsors based on previous usage info and package, 
application and use case statistics (some ideas about direct user 
financial support of a project and sub-projects but not crystalized yet.
- Have implemented "at least one test" process before implementing new 
changes to any repo (while not physically stopping anyone to do 
contribution , but testing should be logical step before inclusion.
- Form willing "testing crew" users pool, that could be sent testing 
requests (depending also on user base area of interests and competence.

So all these tasks are actually not developer-related, but 
administrative-related in a way they are improvements to visibility and 
appearence of the project, and
people that do changes could actually ignore them if they want,
except for a good-will request for using Testing user pool in a more 
sane manner and policy of "at least one test", and they could be a tool 
for better steering

More minimal they are and are not interfering with contribution and 
distribution processes, the better.
I am willing to do on some and all of them and obviously polish those 
tasks even more, as far as my abilities and time allows me. (and others 
abilities and time also do).

Sorry for possible spelling mistakes, I'm no natural speaker and I just 
found out that Thunderbird spell checking sometimes stops working after 
some time, when typing long messages ;)