Hi Garrett, Release tomorrow. Status: http://twitter.com/MartinBochnig
Till then. Martin On Mon, Jan 28, 2013 at 4:06 PM, Garrett D'Amore <[email protected]> wrote: > I'm sorry to open a thread that I'm sure will cause a lot of discussion most > of which will probably be fruitless and pointless. And yet, I feel compelled > to do this. Please think before you respond, and only reply if you have some > thing useful to add to this conversation. > > Recently, I advocated (as in RTI advocacy), a change to a program - kstat. > After I integrated this change, another advocate pointed out that the SPARC > port was broken by this otherwise worthwhile change. In that particular > instance, the advocate took it upon himself to fix the problem. > > However, its clear to me that this particular advocate (Richard Lowe) may be > the only advocate with regular access to SPARC. Its also clear to me that > the vast majority of ordinary developers lack such access to SPARC. > > SPARC is on the brink. > > There in the past have been numerous offers of SPARC hardware. However, as > far as I can see, these offers have come without any hosting, or even > shipping to get the hardware to somewhere where it can be useful. > > Historically, if a SPARC problem arose that broke the build, the change would > be backed out. Sun engineers were expected to build and test their changes > on both architectures before integration. illumos has never had this > requirement, because we have always understood that most developers don't > have SPARC access; but we have still tried hard to keep the SPARC port > working. > > Now the choice is not mine to make alone, but I'm going to strongly advocate > that we simply stop making that effort unless sufficient SPARC resources are > made available to keep the port "healthy". The resources that we need: > > a) Hardware - we need at least three fairly decent configurations (4 CPUs or > better ideally) -- a build system for advocates, a build system open to all > illumos developers, and a reservable "test" system. (A sufficiently beefy > system - e.g. a 12 way system, could be used to serve both of the build > system needs, but I'd still prefer two separate boxes if possible.) In the > past there have been many people who have offered to donate -- in some cases > pretty high end -- SPARC hardware to illumos. We've failed to find a > location for it though. > > b) Rack space for the systems, with sufficient power, cooling, and network > bandwidth for 24x7 operation. We also need remote console access to all > three systems, and ideally some kind of remote power control for at least the > test system. I think we should like to see a 12-month commitment to keep > these things running; we don't want to go to the expense and trouble of > setting them up only to find we have to vacate a few weeks later. Recognize > that two of these systems are going need very wide access to allow any > illumos developer to have access. (We'll do some basic validation of email > addresses, and use public key SSH authentication, and we an even arrange for > a "click to agree" legal agreement process before granting access.) > > c) If "a" and "b" are not co-located, then funds to ship the servers to the > hosting location. > > d) Human resources (administrative) to perform basic system administration > and setup of the above resources, including a calendaring system for managing > the test reservations. I *suspect* that this is the one resource we will > find in plenty once the others are answered. So please wait to reply to this > until we see if a - c are forthcoming. > > So, if we don't have these resources, and nobody is able to provide them, > then I believe we don't have the resources to keep the SPARC port healthy, > and I don't think we should continue to try. In such a case, I'll recommend > that we consider SPARC a secondary port, and not consider its functionality > in deciding whether to integrate new changes or not. (That said, I think > we'll always be happy to accept fixes for SPARC from volunteers who submit > them with documentation demonstrating that they have tested such fixes, but I > imagine that SPARC support will quickly degenerate if we stop requiring SPARC > functionality to work during the RTI process.) > > I do know that some people have been working hard to get a viable SPARC > distribution going. My hat is off to those people. I don't know if we yet > have such a distribution. I know no small level of effort has been invested > there, and it is not my intention to denigrate that effort. > > But even if everything worked perfectly for SPARC today, without the above > resources I don't think we can truly consider the SPARC port healthy. We > need to be able to point developers at resources that they can use to fix and > test their code for this platform. Without that, its not fair or reasonable > to insist that all changes be correct on SPARC. > > Nor is it fair or reasonable to ask the single RTI advocate (who by the way > is also the only RTI advocate who doesn't get a paycheck for illumos related > work!) to maintain this port all on his own. > > In the past I tried be a middleman for this conversation -- it didn't work > out so well. Lots of offers for hardware came, but nobody with resources to > host them, or an ability to ship hardware to the destination. So instead I'm > going invite folks to discuss and solve the problem here. I think its more > likely that a solution will come in an open forum. And if a solution can't > be found here, then it will be obvious to everyone, and hopefully nobody will > think worse of us if we then decide to reduce our commitment to what will at > that point be obviously an unsupportable platform. > > (A brief note about simulators: there are some SPARC simulators. I'm not > aware that any of them are capable of running illumos. If they were, it > would be a huge boon to illumos and SPARC platform support. However, because > hardware frequently differs from emulation, I don't believe the existence of > such a simulation eliminates the requirements I've stated here for a healthy > port. It *would* mean that there would be a reduced demand for the build > systems, I think, and less frequent use of a remote test system, but I think > we would still need these things to be available to the community to keep the > port healthy.) > > Thanks. > > - Garrett > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175665-cebcd593 > Modify Your Subscription: https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.com -- regards %martin bochnig http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.youtube.com/user/MartUXopensolaris http://www.facebook.com/pages/MartUX_SPARC-OpenIndiana/357912020962940 https://twitter.com/MartinBochnig http://www.martux.org (new page not yet online, but pretty soon) ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
