Cyril Plisko wrote:
On Sat, Jan 24, 2009 at 4:48 PM, "C. Bergstr?m"
Some people have offered to help on all this, but so far it's only minor or
I'm blocking things by not giving enough details I think.. I've tried to
file bug reports/RFE at bugs.osunix.org and updating the TODO list(s) on
www.osunix.org, but we need more help from the community and coordination
from those actually doing work to avoid duplication.
I am not sure what other thing, but there is something hat bothers me.
You seems to be investing heavily into that project of yours, but it
is not clear (at least to me) what is the ultimate goal (or goals) of
that builds that you undertake ?
I have tried to dodge this question because instead of creating yet
another distro I wanted to unit the current leaders and all work
together. For this goal I went to Berlin and met with J?rg Schilling,
I've talked with Moinak extensively and most of the other community
leaders. On most any day I could probably ask any of them for small
help and get it if they have time. The 2nd part of this is like herding
cats though and trying to reduce the amount of duplicated work.
After some recent discussions these things will start to change:
1) OSUNIX will become yet another distro.. (I'd like others with
similar goals to merge with us, but can't save the world if they don't)
2) shipping a zone != shipping a hw release
I think if we can answer the question why are we doing this it will be
easier to choose how to get to our goals. Please, do not take this as
an attempt to stall the process, I just think that clear statement of
target and intention will help people contribute actually.
Oh.. I know you're very active in the opensolaris community and don't
take this as an attempt to offset at all, but just wanting honest
Now, if you don't mind, I have a couple of question:
a) onnv-gate is packaged in a very fine grained way
Can you please elaborate more on that ? What package boundaries would
you define to achieve that ?
This is mostly directory based with a few exceptions
usr/src/uts/ == kernel, but I'm also going to glob the base directory
setup in there as well as the header generation..
(header generation I've thought to break out, but opted against it for
now. Also I'd like to micro package the kernel, but that will require
Makefile changes and more work)
usr/src/lib/* == each gets an individual package
usr/src/cmd/* == each gets an individual package
Each package is by default tightly coupled per snv_xxx version. So
snv_107 libc won't get mixed with snv_108 kernel or any of the micro
packages. I've also defined a meta build onnv-gate which will resolve
all dependencies and install it just as if you were to run nightly.
Part of the reasoning behind this micro packaging is that if you have a
bug in libavl.so..
a) Knowing exactly where that souce/package is will help developers
b) *IF* there's ever a buggy sun ld (which snv_106 has) you'll be
able to more easily work around this by overriding that package to
another version if a patch isn't available
c) patch management. Since we *are* forking Sun's onnv-gate. The
better the code to patch tracking ratio the easier it is to
I have a more reasons which I can go further into detail about.
b) under new ospkg building and packaging framework
c) We could have a continuous build server to test any bad commits from Sun
What criteria would you use to detect these "bad commits from Sun" ?
bad commit initially will be a change which breaks the build process.
This should *not* happen, but I have no intention to follow exactly as
Sun does and as a result something could break. (compiler, 64bit
cleanness, 3rd party drivers.. etc)
automated QA will come as well, but that's still in the planning phase
d) We could more easily test the CR's dropped
That puzzles me. What is dropped CR ?
Code review.. A perfect example is
Stolen from zfs-discuss
My results are much improved, on the order of 5-100 times faster
(either over Mbuffer or SSH). Not only do snapshots begin sending
right away (no longer requiring several minutes of reads before
sending any data), the actual send will sustain about 35-50MB/sec over
SSH, and up to 100MB/s via Mbuffer (on a single Gbit link, I am
network limited now, something I never thought I would say I love to
So.. wouldn't it be nice if mere mortals could test it? The current process for community testing for non-developers is probably at best scary. Using the new packaging I plan to make it easier to add/roll-back even the most bleeding edge stuff.
e) We're completely free of SVR4
Are you referring to SVR4 packaging or something else ? Correct
f) The difference between snv_10x and svn_10y will be trivial to roll updates.
Exactly how ? Are you talking about ON consolidation as delivered by
onnv repo or the whole SNV ?
SNV.. Anything they push in onnv-gate and tag with snv_ minutes or at
most hours later will be packaged and released with an appropriate QA tag.
g) We'll have a place to apply patches which upstream won't accept
w/o an SCA (eg interface enhancements from J?rg, Moinak, myself and
all the other devs)
That one gets my vote on a spot :) !
As it should.. Mirror is up and if you're in europe will be faster than
Sun's main onnv-gate.. I'm trying to work out commit details for that
and will start in the near future. To me this isn't something I take
lightly since it's the core code and ensuring stability/security is a
very high priority for me.
h) We can test new compilers/toolchains/optimizations very easily and
adjust where we are forced to
i) We can start our own community QA work
j) For any distro who uses our packaging we can all work together on
bug fixes, new drivers etc..
k) Anyone who wants to work on the fully open libc will be able to
easily pull a full working dev environment
h) - k) are pretty clear (but requires significant (titanic, I would
say) effort to actually implement)
You'd be surprised what a couple determined people can achieve.. Once
the community is rolling I'd like to find a way to sponsor our own
development or gain the interest of those commercially invested in
OpenSolaris technology to look at us for help achieving their goals.
For university students I could see it being a lot easier to find a
sponsor to help walk them through the code. Increasing the public
documentation on various aspects of the code and overall doing a lot
more than what's being done. Which for many cases isn't much more than
a cheap repackaging effort.
I hope this brings a bit more clarity. If you have the time I'd love
more feedback on your goals and or help with making sure questions are
If you or anyone else wants to drop by and say hi (I'm codestr0m) on
irc.freenode.net #ospkg please feel free. Sometimes OT, but usually the
best OpenSolaris technology channel around.