[OSUNIX-dev] Infrastructure choices

["C. Bergström"]

Thanks for the good feedback/questions Cyril, please find my comments inline

Cyril Plisko wrote:
> On Sat, Dec 13, 2008 at 2:13 PM, "C. Bergström"
> <cbergstrom at netsyncro.com> wrote:
>   
>> <snip />
>>     
>
> Christopher,
>
> can you please elaborate a little bit more on why you believe these
> tools are necessary. Or rather why the separate instance of these
> tools is necessary ?
>
> 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..

> Anyhow, see below my comments.
>
>   
>> ----------------------
>> My votes currently..
>>
>> Issue tracker and code review for me is hands down jira / crucible.. Even if
>> closed source I find those tools easier to work with and will long term save
>> us time on bug wrangling, setup and maintenance.  Also amount of plug-ins
>> around this is quite good and could help us in many ways.
>>
>> +1 jira/crucible
>>     
>
> I have no direct experience with jira, however, I've heard a lot of
> good words about atlassian tools, so I am in favor of experimenting
> with that.
> Anyway, how easy is to export/import data from/to jira ?
>   
http://www.atlassian.com/software/jira/
http://www.atlassian.com/software/crucible/

import/export for back-up purposes or migration..?  bugzilla > jira

I know bugzilla to jira in some manner is possible, but haven't done it 
myself..
>   
>> [1] git vs hg should not even be brought up, but I know a lot of people are
>> already familiar with hg.  The reasons why not to use git since the initial
>> evaluation have been resolved.  git may offer technical advantages such as
>> partial or sub tree check out.  Git has a larger community and probably long
>> term will grow faster than hg.. (I'm a big fan of hg, but even Chris Mason
>> switched)  Those contributing to other projects (dragonfly bsd, perl,
>> linux/gnu project may already be familiar with git)
>>
>> +1 *distributed* fast scm which will allow partial/subtree check-out
>>     
>
> Can you explain why partial clone/check-out is so important ? You are
> clearly putting it above all other features.
> I also believe that having SCM tool different than that of the
> upstream, will not make the overall operation easier.
>
>   
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 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 if there's a regression/failed merge.. etc.. 
the build system should pick it up within minutes and alert us.

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

./C