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.
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
