On Thu, Jul 16, 2009 at 2:00 AM, Alan Coopersmith<Alan.Coopersmith at sun.com> wrote: > Martin Bochnig wrote: >> On the other hand I do agree that the separation between fox-gate and >> xwin-consolidation should be teared down. Maybe someone of us should >> then get xwin-gate write access. >> I don't know if I would currently qualify for this, as I haven't been >> very active here during recent months. But in general, I mean. > > Write access won't be available to non-Sun-employees until Phase 3 of > the plan, when the master hg gate is moved outside the firewall, but > that depends on a bunch of work being done by the opendev project and > is at least months away, if not longer. ? (I don't think they have a > schedule for that yet.) > > But in the world of the master Solaris/OpenSolaris gates, both currently > and the one envisioned for them once they move to opensolaris.org, write > access isn't really any big deal - no one gets to commit anything that > hasn't gone through the formal review processes, and once that's done > it's just a matter of who gets to type the final hg push command. ? Anyone > who puts back without review gets backed out when the gatekeeper sees the > commit notice (or gets blocked automatically by the gate commit checks). > The gates internally are mostly world writable in Teamware - the hg gates > are writable by anyone with an ssh key on opensolaris.org - though being > internally, the firewall is the big blockade there. > > It's not like the way many open source projects are run, where commit access > is granted only to those who have earned the trust of the community to make > sure their own commits are worthy of going into the shared repo. > > -- > ? ? ? ?-Alan Coopersmith- ? ? ? ? ? alan.coopersmith at sun.com > ? ? ? ? Sun Microsystems, Inc. - X Window System Engineering > >
Thank you for the update, Alan. I feel ashamed that I lag so much behind with my past announcements. You know, I had other things to fix first. But I'm still around. Before above aspects come somewhere near to gain in importance, you know what I (for my part) need to bring in ... * the IPS changes * ast-derived device finding via the fb kernel driver * on x64 changes which fix the current behaviour, where radeon is preferred over radeonhd (on my Laptop). * porting over the minimal unaccellerated XVR-500 and Expert3D frame buffer driver from BSD. That's not trivial, because it depends on a BSD-specific console kernel module. As it is branched off from the original BSD-wsfb Xorg module, which you ported to Solaris, you know what I mean. Without the BSD console driver it may brought to limited functionality under OpenSolaris, but currently only with legacy Ati m64 cards, not with much else. And exactly that doesn't help us at all. Because for the m64 a marginally altered native Xorg module already functions well for SPARC-Solaris. Best I write this up. So that others can join in. As I mentioned last week, I now also have Red SB1500 and SB2500's for testing. Although it is less important now, with the new method of finding the device (without libpciaccess and especially without the old userland Pci-scanning using sparcPci.c on SPARC). But certainly it won't harm to have a more complete testing Workstation-farm. Thanks for the patience with me and regards to you all, Martin
