Brian Gupta wrote:
>> > Perhaps. ;) But first we *all* need to come to a common vision.
>>
>> OKay ... let's write a mission statement and then go from there
>> perhaps.
>
> No point in writing a mission statement if everyone isn't on board.
A certain book by Joseph Heller comes to mind ....
- jek3
>> > One thing I think Sun desparately needs to address, is crediting third
>> > party contributors within Solaris itself. When it was just Sun doing
>> > the development, it was "works for hire", so no credit needed to be
>> > given. Now with unpaid volunteers joining the mix, Sun has to give
>> > credit where credit is due. (Maybe in the man pages? And.or the docs.)
>>
>> That is a Sun Microsystems Inc. issue and not an OpenSolaris.org
>> issue.
>
> Hmm, I don't agree. If things are fed into Express with credits, Sun
> will have to make an active decision to remove them. Doing so has the
> potential to upset the volunteer community, and would probably go a
> long way to preventing growth of that selfsame community.
This will be a hard culture change one way or the other (and its a problem
we [Sun] are aware of). However, isn't this a rather disjoint topic
from the
thread Brian started?
BTW: I had a tizzy-fit when I saw "gnome-about". 8^)
>> > > As for community software, in order for the massive pile of CSW
>> > > software to be integrated into Solaris or OpenSolaris we need to
>> close
>> > > ranks a bit and stop bickering with each other.
With this many inclusions, I don't even know who I'm responding to, but
why is the goal "to be integrated into OpenSolaris". Is everything FOSS
integrated into Red Hat, SuSE or Windows?
The goal should be "easily available for OpenSolaris".
I think it is critical that this differentiation be understood. Perhaps
resolving
any confusion about that is "step 1".
> I meant patience with the speed of the OpenSolaris proposal process,
> and patience with team members that are making sure that the stable
> legacy of Solaris is upheld.
I really appreciate this, but you are initially in a different domain
than the
architectual processes I think you are referring to. Although hard
architectual
problems may exist, I don't believe there is much debate about the general
architectual picture. The hard problems lie in assignment of
responsibility.
WHO builds the packages?
WHO distributes the packages?
WHO supports the packages?
...
- jek3
