On Jan 28, 2008 12:02 PM, Richard Lowe <richlowe at richlowe.net> wrote:
>
> "Shawn Walker" <swalker at opensolaris.org> writes:
>
> > On Jan 28, 2008 11:33 AM, John Plocher <John.Plocher at sun.com> wrote:
> >> Ben Rockwood wrote:
> >> > Let me put this another way... is the only engineering related reason to
> >> > participate in the OpenSolaris community to putback to the ON gate?
> >>
> >> [...obviously OpenSolaris is more than simply the ON gate...]
> >>
> >>
> >> foreach $X in { Thunderbird, WordPress, ApacheHTTPD, Sendmail,...}
> >> ... Is the only reason to participate in the $X
> >> community to putback to the $X gate?
> >> end
> >>
> >>
> >> I'd say, 99% of the time, yes!
> >>
> >> Lets optimize for the common expected use case, not the fringe
> >> "I want to play by myself and fork my own" exception, which is
> >> IMO already handled by the CDDL. If you want to go off and do
> >> your own thing, go for it - the *Community* has no obligation
> >> to help antisocial efforts that will just fragment itself.
> >
> > So, Belenix, SchilliX, and Nexenta are anti-social?
> >
> > I believe that telling people "we don't like what you're doing; go do
> > it elsewhere" is actually the real cause of harmful fragmentation.
> >
> > Encouraging developers to innovate within the bounds of our community
> > and providing a place for them to collaborate helps prevent that.
> >
> > That hardly seems like a "fringe case."
> >
> > If anything it's a sign that a bigger need in the community isn't
> > being properly met.
> >
> >> OTOH, if you are trying to figure out how a community can
> >> encourage both evolutionary and revolutionary changes to itself,
> >> the processes referenced earlier (ON dev process, ARC...)
> >> are designed to easily and actively support both. Maybe there
> >> are other viable options than simply becoming yet another Apache
> >> Project...
> >
> > Those dev processes seem to severely restrict "revolutionary changes"
> > rather than encourage them.
>
> The bounds of change are set by the release binding of the
> destination, and the requested binding.
>
> If you had a Major release gate to integrate to, you could do
> practically anything (within the bounds of sane architecture, but
> ignoring most other things).
I'm aware of the release binding concept. However, others seem to
imply that before work can even begin on something, a formal proposal,
etc. has to be done and something has to go through ARC.
I don't agree with that view.
A developer should be able to start work on something without getting
anyone's approval and only when they are ready to have their work
reviewed (before integration into the main ON tree as an example)
should they be required to perform ARC, etc.
It should be up to the developer when they have to consult ARC, etc.
A good developer will know when the right time to do that is.
--
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/
"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
