[OpenIndiana-discuss] Testing updates from /dev to /hipster-2015 and /hipster

[Nikola M]

On 05/ 6/16 10:25 PM, Tim Mooney wrote:
> For example, the repo for hipster has changed, correct?  Should it
> (in theory) be possible to go directly from /dev to the latest /hipster,
> or is the chance for success higher if one first updates from /dev to
> /hipster-2015, and then (if that works) from /hipster-2015 to the latest?

It is always better to test updates with newest hipster, but in this 
case, since /hipster is moving further away (and it moved also further 
inside /hipster-2015),
So as a convenience , there is currently non-changing /hipster-2015 that 
could be used as target when updating form /dev. (and make changes only 
for the reasons of polishing /dev update)

So if some problem with updating is found, we can spin up build process 
and renew some packages in hipster-2015, while making also the same 
changes in /hipster if it makes better for /dev update.
After that, hipster-2015 -> 20160421 snapshot update should also work 
(we can spin also up temporary unchanging 20160421 repo to test it, like 
dev-testing or something)
If it works right, then it can truly land in /dev like a release , and 
pointing that there are 2 paths from there, waiting for next /dev 
refresh (and posting bug reports in meantime) and updating to /hipster 
to include itself in newest changes.
At some point in time, then landing from /hipster to /dev would be not 
hard task, if all packages are sane enough at that moment.
So /hipster stays wild and crazy, so to speak and people wanting to have 
testing and quality checks before landing in /dev could take part in 
testing.

> There are also some parts of the process that someone very familiar with
> IPS should expand upon.  Mainly, I mean "Uninstall all packages from
> opensolaris.org publisher".  What's the most efficient way to do that?
> "pkg list -v | egrep -i opensolaris" to generate the list?  Is there
> a better/recommended way?

Well during update process to test how it is doing, we can work it out 
what would be the best procedures before updating, so that people get 
sane environment after updating. Those can end up in release notes as an 
extension of existing 20160421 snapshot notes.

> Is it likely that I'll also need to uninstall packages from sfe or
> sfe-encumbered?  I have about 60 of those installed.

This is the great question.
For Hipster (/hipster), there is currently /hipster-encumbered (that 
would need to have it's own respin of publisher into, say /dev-encumbered)
For SFE for hipster, there is currently outside built and maintained SFE 
repo under http://sfe.opencsw.org/localhostoih/ localhostoih .

For SFE to land for /dev, OI would need a  maintainer for SFE packages 
spinned up on OI infrastructure, for /dev .
tommw said that he can help teaching how to set up SFE build environment 
on OI infrastructure.
After localhostoih publisher is built on OI infrastructure and lands 
into, say /sfe-testing, it can be tested how it's update is doing for 
/dev-testing and could be ready to be used with /dev .
(while for hipster it is to stay on external localhostoih for the first 
time, for convenience)

But at the moment main concern is /dev update and sfe can come later 
(and actually to test it out, one could just add localhostoih 
(http://sfe.opencsw.org/localhostoih/) after update.

So at this time, spin up new boot environment and when in it, deinstall 
all SFE and packages, before doing update, to focus on /dev update itself.

>
>> Final result at the end of the year would be to coincide together new 
>> /dev release
>
> Everything I've seen up to now indicates that /dev is dead and no
> additional effort will be put into any updates or maintenance on it.  Are
> you saying that a hipster "snapshot" might be considered stable enough
> to copy it to the /dev repository, so that it's treated as an update
> for people that are still on /dev? 

Yes.
It includes security updates, it includes many new and updated packages, 
newest illumos also includes security updates, only thing it also 
includes is incompatibility with older binaries.

-With binaries compatibility issues is where making branded zone for 
151a8/a9 comes to mind,
where people migrating will have a place to run those old binaries, 
before migrating to something newer (or leave them forever if that's 
what they want , if existing Solaris 10 zone is not good for them).

-With also renewed and inclusion of packagemenager and updatemenager,
I am exactly saying that people still on /dev could actually get a new 
release that is in-line with alive /hipster and that makes what people want:
Release process with more people and easy inclusion in newest 
development in /hipster, as anyone could jump in and make new and better 
things, that would end up in the next /dev update.

As side note, it is unfortunate that updating /dev wasn't done like 2 
years ago or something, or even that /dev itself wasn't updated directly 
but it moved to /hipster,
Then more people would be included we wouldn't be loosing people for 2 
years and we would probably have what I am talking about 2 years ago.
It's probably the cost of building everythin with GCC instead of Studio, 
plus the need to have more space for experimentation then dealing right 
away with all updates.

I myself used to update from 151a8 to /hipster at one moment in time 2 
years ago so that is the reserve option, to find that moment in hipster 
history and make that update point that works, and then make updates 
through all hipster ISO snapshots till newest, but I guess
we better test /hipster-2015 now and see if there is no many things to 
fix to update from /dev.