[indiana-discuss] what's next?

[Richard Lowe]

Ian Murdock wrote:
> First of all: Welcome!
>
> Now what?

I've been trying to stay out of this, but this one needs a response, I guess. :)

> In my view, the work we have to do falls into five buckets:
> 
> 1. What's the starting point, and what process/infrastructure
> do we need to manage its evolution? Are we starting with Solaris Nevada
> builds and (presumably) moving the binary/package/CD build process,
> C-teams, etc. into the community over time? Or are we building new
> process etc.? I'm unfamiliar enough with how things work today
> that I'm a bit apprehensive about this, but at the same time,
> I've done this enough times in Linux to know it's doable in a
> fairly short timeframe even if we have to start from scratch.
> Need to have a serious discussion of the various options here.

This is a more complicated question than you're probably aware.

We (meaning OpenSolaris, not Indiana) should have C-Teams, we don't mainly 
because nobody has actually fixed that yet.  The gates of the opensolaris 
consolidations are OpenSolaris, and thus the C-Teams should be too, the fact 
they aren't is a bug.  I'd far rather see effort to fix that, than to 
replace it.

The OpenSolaris processes are also not Indiana's to change, any more than 
they are anyone elses, you'd need to propose such things to the OGB.

> 2. What is in "the core OS"? Clearly, if we're shrinking something
> that ships on 6 CDs/1 DVD to 1 CD, we're going to need to
> cut things. Also, are we providing roughly what someone
> familiar with Linux would expect? Where are the gaps etc.?

The "Core OS" is historically ON.  That's almost certainly not what you 
want, however.  OpenSolaris, is OpenSolaris, ON, SFW, JDS, X, NWS, G11N, Man
(and maybe more I forgot).  It's possible that given how much of those 6 
cd's aren't actually opensolaris, that culls enough to fit.

Larger change in the context of Indiana also poses an engineering problem, 
given the package creation process is in the relevant gates, do you intend 
to maintain child gates with the changes you desire/need, or do you expect 
the Nevada (hah, OpenSolaris) gatestaff to run two gates, and spin two 
builds, or do you expect Nevada to change to fit with your wishes?

The latter bit there is going to take a lot of thought (and negotiation 
probably), with OpenSolaris at large (as they're our gates), no doubt some 
of the Sun people who seem to forget that they're our gates will have input 
here too, in the context of Solaris.

> 3. Package system. This isn't just pkg-get or apt-get on top of #2,
> but just as importantly, the framework and tools for community members
> to contribute packages. This is where I expect to have the bulk of
> community involvement. Someone finds their favorite tool isn't packaged,
> so they package it. That's certainly how Debian/Ubuntu have worked.

I have such a large set of problems with this aspect of things, I think it's 
probably best I ignore that one.  There's *far* bigger questions than "How 
will it be done" however.

> 4. How to deliver on "laptop support"? This is the tricky bit if
> you ask me. It's taken Linux years to get to the point where
> it's mostly usable on laptops. Where are the major pain points? Power
> management and wireless networking seem like obvious ones. How do we
> make a quantum leap here? Can we leverage virtualization? Can we "port"
> Linux or Windows drivers to Solaris via a shim layer?  We obviously
> can't do everything in the first pass, but we can identify
> the two or three highest bang for the buck areas to focus on for v1.

As I understand your proposals, Indiana itself doesn't intend to do much 
engineering work outside of the Distribution aspects.  So a question like 
this would really be one for the laptop and device driver communities.

> 5. "Raising the bar", i.e., why come over to Solaris once the adoption
> barriers are gone? 

You're still yet to define those barriers in any meaningful fashion (the 
general "You")

> Some ideas: ZFS root by default is an obvious win, as
> is using ZFS to snapshot before updates to implement rollback. How about
> an AMP stack with integrated DTrace probes? Or "Solaris as hypervisor",
> i.e., making installation on the bare metal involve just laying down the
> core bits needed to spin up Containers and Xen domains, and stage two
> involves provisioning new VMs, something that Linux does poorly.
> Again, not much we can do all at once, but we should set aside 2 or
> 3 of the highest bang for the buck items and work on
> them. We've certainly got plenty of raw material to work with here.

That's the more interesting part of all the proposals, honestly.  "How do 
you intend to make this better", the first step would be "Better than the 
other distributions" never mind better than whichever other system.

-- Rich