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 ;)
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
