Keith M Wesolowski <[EMAIL PROTECTED]> wrote:

> On Mon, Jun 25, 2007 at 07:06:48PM +0200, Joerg Schilling wrote:
>
> > I have been told that you cannot introduce new things into OpenSolaris
> > in case that there is an unasked expert inside Sun. Now we have OpenSolaris
> > and this needs to be extended to the OpenSolaris community.
>
> You are absolutely correct that the entire community, not just Sun
> employees, need to be involved.  But as James and others have pointed
> out, the process of becoming involved requires that you speak up, not
> so much that others are required to consult you and prohibited from
> making progress until you've replied.  The latter would rapidly
> degenerate into a web of dependencies blocked on people who are too
> busy, too disinterested, on vacation, or otherwise unable or unwilling
> to participate.

The current practice of having the important ARC case closed from the public 
creates a web a projects blocking others.

You may be correct in the general case where people cannot know about other 
people's intersts. In these cases, the only help is to discuss plans in the 
public to allow others to point to problems. In the specific case of the tar 
extensions, I would expect that people with enough expertise to be able to 
discuss tar related extension know about star and me.

The main problem was not to discuss the related ARC case in the public.
This must change and I believe that the current way of presenting ARC cases 
that look already "ready" results in opening the process too late.

If there should be something that allows to really consult an ARC proposal, 
there needs to be a way to discuss things before they are presented in a way 
that looks complete already.


> I agree with you that closed ARC cases are harmful, and if you've been
> following the ARC process discussions elsewhere you would know that I
> am a committed and active opponent of that strategy.  As you correctly
> point out, closed ARC cases deny you the right to participate in
> making decisions that will later affect you.  That is wrong.  But
> neither is a project team obligated to approach you when beginning
> work; they may do so if they believe you can help them understand the
> issues, but it is not a requirement.  If the C-team or RTI advocate
> feels that a change is not complete until you have reviewed it, they
> may instruct the project team to seek your counsel.

Let me ask a simple question in order to make it easier to understand the 
background: Would a team that is going to prepare an ARC case that affects ZFS
do this without doing into a discussion with the ZFS team?



> Given these constraints, what do you believe should have been done
> differently here (besides the technical changes you've suggested)?

I like to see an atmosphere where one could not get the impression that
some people argue with the background: "Some animals are more equal than
others and I may be part of them".

As I mentioned before, true collaboration between people inside and outside Sun 
could be something that no other OS platform can deliver today.


Back to being technical...

In the special case of Sun's tar implementation, the biggest problem is that
the documentation is incomplete and that there are many completely undocumented 
features. As I mentioned already, it would help if we agree on that the current
/usr/bin/tar may be replaced by star without the need to implement features
that are either not documented (in public) at all or that have no documentation 
for the related archive format on June 25th 2007.

For the future we need to find a way to prevent a repeat of the problem.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
       [EMAIL PROTECTED]                (uni)  
       [EMAIL PROTECTED]     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to