[OSUNIX-dev] Infrastructure choices

["C. Bergström"]

Cyril Plisko wrote:
> 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 ?
>
>   
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
>> 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.
>   
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
> derived materials.
>
>   
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
> upstream ?
>
>   
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
> agorot.
>
>   
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 
rethinking..

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,

./C