[OSUNIX-dev] Build progress + Vote on project direction

[Cyril Plisko]

On Sat, Jan 24, 2009 at 4:48 PM, "C. Bergström"
<cbergstrom at netsyncro.com> wrote:
>
> Hi everyone!
>


Hi Christopher,

[...]

> 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 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.

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 ?

 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" ?

 d) We could more easily test the CR's dropped

That puzzles me. What is dropped CR ?

 e) We're completely free of SVR4

Are you referring to SVR4 packaging or something else ?

 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 ?

 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 :) !

 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)

-- 
Regards,
        Cyril