Hi everyone..

To jump right in I'd like to define the most important goal

*Build a sustainable development community around OpenSolaris technology*

Any specifics can be discussed later, but some high level overview

Development
1) Better inter-project communication
2) Lower the threshold for developers (easier patch review process,
better and clear documentation for getting started)
3) To actively participate in Sun code reviews
4) Ability to bring community issues into focus (security issues,
specific bugs or things like open source libc project)
5) Encourage collaboration for new ideas. (how to improve zfs,
performance enhancements, new arches and or just cool bits)
6) Did I mention fix bugs....

There's no way I could make an exhaustive list, but I think this should
give some sort of idea.

I consider this a developer list, but may infrequently announce new
resources or ask for feedback in another list/offline/irc for:
Community
1) Community supported infrastructure
a. Website
b. Issue tracker
c. Mailing list(s)
d. Blogs
e. Wiki
f. Forums
g. Developer sandboxes (devzones)
h. QA/Automated build system
2) Group meetings

Marketing/Evangelizing
1) Fund raisers to allow for direct sponsorship of projects
2) Internationalization documentation to allow non-native english
speakers to be more comfortable (I put this under evangelizing since
it's really about bringing more people into the community)
3) cool t-shirts

-------------
*Mailing list etiquette*
http://www.freebsd.org/doc/en/articles/mailing-list-faq/etiquette.html
-------------

Roughly what I've been working on:

1) Modular checkout and changing of how onnv-gate is built
2) Independent evaluation of certain OpenSolaris technology packaging
3) Porting 32bit only libs to amd64
4) Changing onnv-gate to not build with stab
5) Generally porting applications from gcc to sun cc (mplayer,
libffi, liboil, python - which depended on libffi...)


Some of my specific areas of interest are:
1) Automated build, profiling/optimizaing and QA systems
2) Entirely open source based OpenSolaris
3) Enhancing posix compliant tools instead of using non-posix gnu tools
4) Router/voip/storage appliances
5) Porting applications to sun cc/alternative compilers

-------------

Some questions to everyone in the group..

1) What's your background?
2) Have anything you've worked on and want to share?
3) Have any specific problems you would like to see this group help you
with?

So with this I want to wish everyone a big thanks and hope we can all
build something interesting.

Kindly,

Christopher Bergstr?m

codestr0m #ospkg // ##opensolaris irc.freenode.net

Search Discussions

  • Moinak Ghosh at Dec 12, 2008 at 4:53 am
    This is a nice list. Regd. "Entirely open source based OpenSolaris",
    one of the biggest sticking
    points is the closed libc_i18n stuff. The Emancipation project was
    started to address this but it
    seems to be going nowhere. Additionally there are some closed drivers.
    Masayuki Murayama
    has open-source alternatives to some closed NIC drivers. We can help
    testing those and provide
    feedback to him.

    Regards,
    Moinak.

    On Wed, Dec 10, 2008 at 10:16 PM, "C. Bergstr?m"
    wrote:
    Hi everyone..

    To jump right in I'd like to define the most important goal

    *Build a sustainable development community around OpenSolaris technology*

    Any specifics can be discussed later, but some high level overview

    Development
    1) Better inter-project communication
    2) Lower the threshold for developers (easier patch review process, better
    and clear documentation for getting started)
    3) To actively participate in Sun code reviews
    4) Ability to bring community issues into focus (security issues, specific
    bugs or things like open source libc project)
    5) Encourage collaboration for new ideas. (how to improve zfs,
    performance enhancements, new arches and or just cool bits)
    6) Did I mention fix bugs....

    There's no way I could make an exhaustive list, but I think this should give
    some sort of idea.

    I consider this a developer list, but may infrequently announce new
    resources or ask for feedback in another list/offline/irc for:
    Community
    1) Community supported infrastructure
    a. Website
    b. Issue tracker
    c. Mailing list(s)
    d. Blogs
    e. Wiki
    f. Forums
    g. Developer sandboxes (devzones)
    h. QA/Automated build system
    2) Group meetings

    Marketing/Evangelizing
    1) Fund raisers to allow for direct sponsorship of projects
    2) Internationalization documentation to allow non-native english speakers
    to be more comfortable (I put this under evangelizing since it's really
    about bringing more people into the community)
    3) cool t-shirts

    -------------
    *Mailing list etiquette*
    http://www.freebsd.org/doc/en/articles/mailing-list-faq/etiquette.html
    -------------

    Roughly what I've been working on:

    1) Modular checkout and changing of how onnv-gate is built
    2) Independent evaluation of certain OpenSolaris technology packaging
    3) Porting 32bit only libs to amd64
    4) Changing onnv-gate to not build with stab
    5) Generally porting applications from gcc to sun cc (mplayer, libffi,
    liboil, python - which depended on libffi...)


    Some of my specific areas of interest are:
    1) Automated build, profiling/optimizaing and QA systems
    2) Entirely open source based OpenSolaris
    3) Enhancing posix compliant tools instead of using non-posix gnu tools
    4) Router/voip/storage appliances
    5) Porting applications to sun cc/alternative compilers

    -------------

    Some questions to everyone in the group..

    1) What's your background?
    2) Have anything you've worked on and want to share?
    3) Have any specific problems you would like to see this group help you
    with?

    So with this I want to wish everyone a big thanks and hope we can all build
    something interesting.

    Kindly,

    Christopher Bergstr?m

    codestr0m #ospkg // ##opensolaris irc.freenode.net



    --
    ================================
    http://www.belenix.org/
    http://moinakg.wordpress.com/
  • Piotr Jasiukajtis at Dec 12, 2008 at 10:09 am

    Moinak Ghosh pisze:
    This is a nice list. Regd. "Entirely open source based OpenSolaris",
    one of the biggest sticking
    points is the closed libc_i18n stuff. The Emancipation project was
    started to address this but it
    seems to be going nowhere. Additionally there are some closed drivers.
    Masayuki Murayama
    has open-source alternatives to some closed NIC drivers. We can help
    testing those and provide
    feedback to him.
    Yes, I will test Masa's latest alta driver in the near future.

    Btw, I CCed Masayuki.

    --
    Regards,
    Piotr Jasiukajtis | estibi | SCA OS0072
    http://estseg.blogspot.com
  • Christopher Bergström at Dec 13, 2008 at 12:13 pm
    Hi and good weekend everyone..

    Decisions about infrastructure choices is around the corner and wanted
    to ask those on the list for feedback.. If there are specific
    tools/features you find particularly helpful or important please make
    suggestions now.

    I'm open to both closed source products willing to sponsor our community
    or entirely open source tools. Personally, I'm less religious on this
    and more about efficiency and solving real problems..

    I'm hoping this doesn't turn into a messy thread, but some of the things
    under consideration:

    1) Issue tracker (jira, bugzilla, mantis, google code, bitbucket,
    or.. ?)
    2) Code review tools (webrev, crucible, or..)
    3) Forums
    4) Do we want a wiki or is there a better way to handle this
    5) hg vs git? (Please read note [1])
    6) Blogging platform

    I'd prefer to handle this in some organized.. vote + reason manner
    why/concerns manner
    ----------------------
    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

    For the other things I think it falls in two columns for me.. redmine or
    clearspace community

    I'm highly partial to the new clearspace community and see it as solving
    a lot of problems in a coherent organized manner. The problems which
    exist in the current jive forums has been solved. If we don't want to
    integrate the forums with the mailing lists if we don't have to.

    +1 clearspace

    [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

    +1 typepad.. The guys at typepad have been kind enough to offer us a
    good discount. With this I can probably afford to host *a lot* of
    blogs. (A few months back I evaluated almost every blogging platform I
    could get my hands on and with the updates typepad made recently I think
    it's a really good choice..)

    Cheers,

    ./Christopher
  • Cyril Plisko at Dec 13, 2008 at 7:16 pm

    On Sat, Dec 13, 2008 at 2:13 PM, "C. Bergstr?m" wrote:

    Hi and good weekend everyone..

    Decisions about infrastructure choices is around the corner and wanted to
    ask those on the list for feedback.. If there are specific tools/features
    you find particularly helpful or important please make suggestions now.

    I'm open to both closed source products willing to sponsor our community or
    entirely open source tools. Personally, I'm less religious on this and more
    about efficiency and solving real problems..

    I'm hoping this doesn't turn into a messy thread, but some of the things
    under consideration:

    1) Issue tracker (jira, bugzilla, mantis, google code, bitbucket, or.. ?)
    2) Code review tools (webrev, crucible, or..)
    3) Forums
    4) Do we want a wiki or is there a better way to handle this
    5) hg vs git? (Please read note [1])
    6) Blogging platform

    I'd prefer to handle this in some organized.. vote + reason manner
    why/concerns manner
    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 ?

    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 ?
    [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.

    --
    Regards,
    Cyril
  • Christopher Bergström at Dec 13, 2008 at 9:13 pm
    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"
    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
  • Cyril Plisko at Dec 14, 2008 at 9:09 pm

    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.

    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
  • Christopher Bergström at Dec 14, 2008 at 9:40 pm

    Cyril Plisko wrote:
    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.

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouposunix-dev @
categoriesopensolaris
postedDec 10, '08 at 4:46p
activeDec 14, '08 at 9:40p
posts8
users4
websiteopensolaris.org

People

Translate

site design / logo © 2018 Grokbase