[oi-dev] Hipster stable future and update of /dev , Xorg intel solution for hipster-2015

[Nikola M]

Making stable out of Hipster 20141010 would not be productive before 
devising safe update from latest /dev release.. So we might discuss that 
first.
At least that goal (that updating from /dev to newer /dev is important 
for Openindiana) needs to be accepted as a goal of making move toward 
stabilizing on Hipster ways.

It is still questionable wither Hipster's abandoning code 
consolidations, to enable faster pace of updates (and alongside 
breakages with less testing here and there) is viable path toward future 
of OI.

How to make every update have it's own "entire" to update to, without 
re-using code consolidations?
How to control random update changes on the level of sub-systems that 
are interconnected and mutually dependable and separately testable, 
without code consolidations?
If future update from /dev to newer /dev would have no previous code 
consolidations, if benefit from it largely greater then benefit of 
locking versions that are actually already tested of working together 
before?
(and need testing as a whoe before inclusion of changed packages)
It all smells like there's need for a bit more complicated update path , 
even for Hipster.
And not every update in Hipster could end up in next release for wide 
audience (e.g. some changes can die sometimes).

Letter continues after the quote:

On 02/25/15 05:55 PM, Alexander Pyhalov wrote:
> If someone wants to support alternative branch (e.g. /hipster-stable 
> or /hipster-obsolete), he has to
> a) create build server using old ISO (and not updating any package),
> create new branch at 94c63b33550c4fee818b1423a16eb5c3a775681a, rebuild 
> repository and support alternative build server for this branch.
> b) support this branch (at least backport security fixes from the main 
> one)
>
> Are there any volunteers?

I actually proposed updates from hipster-2014.1 to hipster-2015 get 
another branch, like hipster-2015-oldX or so.
That would get same updates and testing as hipster-2015, just with 
"normal" workign Xorg and intel drivers that actually works for most 
people. (as oppose hipster-2015 with X that works only with newer Intel 
hardware, I suppose).
There could be some updates ommited or applied differently so that X 
would continue to them as oppose X not working right for one (I suppose 
bigger) part of the audience and working for others.
All other updates could be the same.

Other path could be making available another set of Xorg and Intel 
drivers in mainline hipster-2015, that would allow "business as usual" 
inside ever-changing Hipster repo, just people could choose them 
according to hardware they use.
Tricky is that both X and driver needs to be different but since 
previous Intel driver actually works with current illumos and new driver 
actually does not because it lacks KMS in illumos, it was actually 
better solution to leave old X and driver in-place and have newer X and 
driver as selectable alternative for install.

Another (and maybe cleanest) way to fix Intel driver problem, before 
update of X and Intel graphics was done is there could be aether 
"re-start" of hipster-2015 (people can always udate from 20141010), 
where X and Intel are same as in 20141010, but there are additional X 
and intel drivers for new intel hardware, waiting for illumos KMS 
support (that could land aether with patch or through illumos).

It's not like Hipster is only one way street, nor it could be looked in 
that way, breakages will come and there are more then one way of dealing 
with them then just updating packages.
If something does not work, it could be scratched and made right before 
moving on.

> As for patches for illumos-gate, we support them, but only small and 
> really necessary. Even if we got KMS patch (and we don't have it), it 
> should be adopted by illumos, as it's the only way to ensure that it's 
> properly supported. 
That's certenly one way of dealing with things.
If brings benefits as you said, but the lack is inability to act in 
time, to have new things included in illumos and distro and actually 
_test_ them _before_ they are even included in illumos.
If no one test things before they are in illumos, then timeline for 
illumos inclusion would be much longer and actually never land inside 
illumos to become part of the Hipster.
As ever-testing ever-updating (someone would say "bomb-shelter") 
rolling-release, Hipster needs to test wild and crazy things exactly to 
be able to support inclusion of new things in illumos.
It can not be shielded from testing new things before illumos inclusion.

Benefits of using only upstream illumos could be used inside another 
"development" OI (mostly like you described as going toward "stable" 
Hipster (And what I would call updating to new /dev from/includin 
Hipster changes) and that is actually not in the spirit of "open for 
experimenting" Hipster for Hipster to be closed for illumos extending 
experimentation.
Actually aether new X and Intel driver stays in Hipster-2015, or it gets 
scratched and new packages made available as optional, there is need of 
updating illumos with KMS to support that, so by accepting new X and 
intel driver, Hipster must accept also some non-upstream patches.