On Sat, Dec 13, 2008 at 11:13 PM, "C. Bergstr?m" 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.


1) The open libc work.. I need to attach patches and comments to the issue
2) the incompatible gnu tail and Roland's solution are on there and now
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
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


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 8 | next ›
Discussion Overview
grouposunix-dev @
postedDec 10, '08 at 4:46p
activeDec 14, '08 at 9:40p



site design / logo © 2021 Grokbase