[OSUNIX-dev] Infrastructure choices

[Cyril Plisko]

On Sat, Dec 13, 2008 at 11:13 PM, "C. Bergström"
<cbergstrom at netsyncro.com> wrote:
>
>>
>> For example, with issue tracker - what sorts of issues are we going to
>> track ?
>>
>
> Short answer.. lots.. right now on the google code project I have 32 and I
> imagine that will expand out to 100+ over the next two weeks.. (while at the
> same time issues are being constantly resolved)  I was tracking them locally
> before, but publicly doing it allows others to see what's going on.
>
> Examples:
>
>   1) The open libc work.. I need to attach patches and comments to the issue
> tracker
>   2) the incompatible gnu tail and Roland's solution are on there and now
> documented
>   3) svc.configd segfault I ran into should be on there
>
> Anything you think is a bug in any opensolaris technology which affects our
> group can/should be on there..
>

So, you are basicly want it for projects running under this community
? Correct ? Do you expect that issues that will be tracked here would
be also tracked at other issue tracking systems, like
bugs.opensolaris.org or defect.opensolaris.org ? If so, what kind of
interoperability between those systems would be necessary, if any ?

> I'm hoping that by reducing the complexity and effort in order to get
> started with the onnv-gate codebase we'll be able to teach and attract more
> developers.
> Hypothetical bug -
>   New possible developer goes on the issue tracker looking for any low
> hanging fruit/challenge/discovers a bug that affects his/her use case
>   The bug is possibly in libfoo
>   Currently the developer has to pull the entire 745MB of onnv-gate to
> rebuild libfoo which is 3 source files
>   Proposed solution will be able to pull only libfoo,
>       rebuild with -g
>       fix/debug the problem
>       rebuild without -g
>   This will all be done under the safety of the package manager.  I am
> currently doing this, but keeping a pristine copy of the onnv-gate and
> copying/rsyncing libfoo over to a temp location.
>

I have a couple of notes on this.

1. ON build architecture has no modular build support whatsoever right
now. So one going to bring everything anyway.
2. The entire ON consolidation is around 220 MB of downloadable
materials (and that is after NWS merge). Anything beyond that are
derived materials.

> I do fully agree that hg is the most logical choice.  With a modular
> approach I think it'll also easier for developers to take ownership of
> certain blocks of code and maintain patches against them.  git <--> hg is a
> pretty straight forward and documented process..  (Correct me if I'm wrong,
> but I think  all commits to onnv-gate are also posted to a patches list?)
>  We can pull/merge automatically from that as a last resort.. In any event
> I'd like to do additional QA on top of whatever is happening inside Sun and

In order to do anything meaningful (QA-wise) we'll need to know what
exactly is done inside Sun, to avoid duplication of effort.

> if there's a regression/failed merge.. etc.. the build system should pick it
> up within minutes and alert us.

Chances that obvious things like that will never make it into
onnv-gate due to CRT existing procedures. So building our process
around checking for straightforward mistakes may appear useless. Or
were you talking about these problems in downstream code, rather than
upstream ?

> I agree that many of the things I'm asking about we don't need *right* now,
> but some of them we can use in the near future.  (Once solid infra is in
> place I'll feel more comfortable doing proactive marketing for our
> community.  This is really the bottom line for why I'm trying to pre-plan.)

I am a big fan of "solve the problems as they arrive" approach. It
saved me a lot of time and resources and nerves in the past. Just my 5
agorot.

-- 
Regards,
        Cyril