[OpenIndiana-discuss] Hipster upgrade problem

[Nikola M]

On 11/16/15 12:02 PM, Stefan Müller-Wilken wrote:
> Hmmm... so the better approach for Internet facing nodes is to move on to /hipster but be defensive in your update policy? Because with what you say and in contrast to Udo, I'd rather call /dev than /hipster going nowhere as more and more /dev packages have reached EOL in their respective projects.
>
> One thought: would it be possible to tag certain Hipster revisions as 'de-facto stable' and publish a small tutorial how to upgrade to such point releases? I feel we'll need a sort of stable ground to convince people to put faith in OI.

Yes, that is a valid idea, best ting is to make new /dev out of hipster 
and at some frozen hipster state that is tested for upgrade and works 
and that would land into the /dev, while hipster continues on it's course.
It needs involvment of the people in making OI and not only using it.

So selecting contribution area , depending on abilities, time and 
expressing opinions, documenting and/or financing it, would be the best.
Lurking at the Oi Wiki 
(http://wiki.openindiana.org/oi/OpenIndiana+Wiki+Home) and joining 
regularly on Freenode's #openindiana and #oi-dev with Xchat or other ITC 
client could make targeting contributing areas more clear.
There are some problems/projects to achieve that:

-Source code availability: Having all source code for all components 
available, versioned on Openindiana servers, and Oi build from them, 
before updating to such hipster-grown /dev.

-Binary compatibility for legacy applications: If hipster changes land 
into /dev ,
one can not expect to just continue running existing packages, but maybe 
inside branded zone with newest studio compiled /dev packages for 
compatibility with legacy applications.

-Testing hipster with updating form dev and fixing current state of 
hipster: Hipster is not de-facto stable ATM (maybe it is for the server 
part), and needs aether upgrades and new users of it and contributors to 
come to a state where it could become new /dev.

-Downgrading packages ability in Hipster: Have ability to downgrade 
packages to the versions that used to work before refreshing it or 
contribution, before newly intoduced bug is fixed.
That also goes with usign 'entire' for jumoing in between package states 
to be able to do testing before pushing it in /dev (there is 'entire' 
now for oi-userland)

-Mindset about where hipster and /dev come together:
If /dev is for general use and deployment with bug reporting in between 
/dev, and hipster is for development in between 2 /dev releases,
then if one looks that way and new /dev releases come it timely manner , 
not too often and not less then 6 times a year,
then the release and testing cycle could work, providing people actually 
update using Boot environments as fail-safe and report bugs in between.
Hipster could land into /dev more often and that woudl be better from 
deveopment and testing point and can require less people, but it would 
need more involvment of existing peopel in keeping quality high.

This talk about upgrading /dev should be happening 2 years ago instead 
of now as I mentioned I used to upgrade form /dev to hipster form 151a8 
and that was a moment to freeze it,
but now, thankfully to great work of Hans Rosenfeld thah moment is here 
again.