[illumos-Developer] Closed-bin accords of the OpenSolaris conference... / was: Re: illumos_145 i386 build status

[Joerg Schilling]

"Garrett D'Amore" <garrett at nexenta.com> wrote:

> > Did you ever think about asking the current OGB?
> > The OGB has the advantage of being an already elected committee.
>
> Yes, I considered that.  And rejected it.  The OGB is a 100% ineffectual
> committee.  I do not believe the problems with Oracle are wholly to
> blame here.  I have no desire to repeat the particular governance
> mistakes of OpenSolaris.  Again, the idea here is that the board is a
> meritocracy, not a popularity contest.

I am a member of the current OGB and for this reason, I know that the OGB is 
definitely not ineffectual but just suffers from Oracle's blocking strategy.

> > If you are looking for people to contribute code, you need to give them a 
> > chance to do so. From my current information you are currently the only person 
> > to do this.
>
> Actually I'm not.  But I'm not going to leave the gate wide open either.

Well, I don't know of any code that was added by someone else.
If there is such code, I would be interested to know.

> So far I don't think I've received any code that is 100% ready to
> integrate yet from anyone else, except for some stuff that seems to be
> somewhat contentious (and is therefore not ready to integrate.)
>
> I'm trying to give preference right now to the critical code bits that
> help us eliminate critical closed deps.  So I need most urgently sed and
> tr.  (Especially tr.)
>
> If Roland can get his ksh93 derived tr ready in a workspace (without any
> other changes except adding tr), then I'll probably integrate that this
> week.

I hope you remember that I reported a bug against ast-tr. I hope you understand 
that we cannot replace tr by a program that does not currectly support something
obvious like:

	tr '[:upper:]' '[:lower:]'

Roland knows about the problem, but we don't have any comment from him on this 
bug. Let us discuss the tr replacement after we have a working solution for tr. 

Note that if we have the FreeBSD i18n implemenation in libc and if you add:

	iswrune() to iswctype.c again (you removed it before)
	nextwctype.c (curently missing)

then it is a matter of less than one hour to make FreeBSD tr run on 
OpenSolaris. If you don't like to add these functions, they could even be added 
locally to tr as long as the symbol "_CurrentRuneLocale" is not hidden (this
means it needs to be explicitely mentioned in the linker map file for libc).
BTW: It seems to be interesting that even FreeBSD tr needs to have access to 
non-POSIX enhancements in order to be able to work.

If you have a binary libc with the FreeBSD i18n code for testing with 
LD_LIBRARY_PATH, I could do the port and basic testing in case it at least
exports the symbols that I would need. So the easiest way to create a version
that is useful for this kind of testing, is to re-link this libc using an empty
map file.

FreeBSD tr is 100% POSIX.1-2004 compliant.


> Likewise, if star is ready to go and doesn't have other contentious

The star integration bits are out for testing since a week. We need to decide 
on the copyright messages in the makefiles and it currently creates empty lint
libs (something that can be easily changed soon after the integration).

> changes, then I'll probably integrate it (although at a lower priority
> since it doesn't hit are primary goal of replacing closed bits yet, and
> the "pax" debate is still unresolved.)

As long as this means that the debate is still in a state that has an open 
outcome, I can live with this state. 


As you mentioned, we need to have discussions that are able to create a 
consensus. This is however only possible if the discussion has an open outcome.


Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily