Cyril Plisko wrote:
On Sat, Dec 13, 2008 at 11:13 PM, "C. Bergstr?m"
For example, with issue tracker - what sorts of issues are we going to
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 ?
Sure. I'm sure there is duplication between nexenta's bug/issue
tracker.. sun's corporate one.. opensolaris.. do they work together..
maybe the opensolaris and sun one, but outside that it'll only be
logical that people using anything under our community report it to us.
If someone takes it and pushes it upstream for some reason or they file
in two places.. it's just doing the best thing and trying to resolve the
issue.. Now.. if you tell me that we should weekly import and scan any
bugs from the opensolaris website.. I'd want to make sure to get
permission from their legal and admin team, but I'm open to that as well..
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.
Yes it does.. I have done it..
2. The entire ON consolidation is around 220 MB of downloadable
materials (and that is after NWS merge). Anything beyond that are
I'm talking about the onnv-gate hg checkout.. Which last time was about
745MB Afaik they stopped offering nightly source tarballs?
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 their QA process isn't open, it doesn't exist to me.. I expect and
hope we can duplicate some level that's meaningful to us.
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
Not true.. they currently support only SS12.. I'm building with
SunStudioExpress and possibly open64 or another compiler in the future..
Once we go entirely open source new arches may have other compilers as
well.. With this the chances of a regression go a lot higher. Also take
into consideration I'm building the whole onnv-gate as 64bit.. The only
exception that technically may be too much of a pita is grub, but I
haven't tried that yet/recently.. (Explanation of this is an entirely
different thread, but it's part of my work)
(Side note: there's also performance regressions and probably infrequent
I do want to know about them.. Sun does a process internally, but how do
we externally know if/when it happened.. how to work-around it or so
many other things to consider.. I just don't want to take the source..
rebuild and call it something new.. Anyone can use distro creator and
feel like they've done something different, but...)
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
Well. in many ways. 5 agorot is pricless...
1) keeps things in perspective
2) if something can't withstand even the smallest level of scrutiny
then maybe it needs rethinking.. and even if it can. maybe it needs
Most of the things I'm trying to solve are things I am facing now or in
a 1-2 week period...
For example.. new developers every day are asking me.. How do I do xyz
in OpenSolaris.. where xyz may be compile onnv-gate, build mp3
support/multimedia center/port application.. there's existing
communities of developers we can try to tie together and with better
communication achieve more.. Belenix devs has patches.. Shillix has
patches.. I have patches.. Masayuki Murayama has made some great stuff
and how do we solve the problem of all communicating better..
You're right though.. I'll evaluate and plan and if there is a problem
someone will let me know..
Hope you and everyone else reading this had a nice weekend,