[OpenIndiana-discuss] New OI /dev release, release structure

[Nikola M.]

> It would also be nice to see a split between home-usage and (partial) professional usage.
> For the way I use OpenIndiana I don't need a GUI, nor firefox nor codecs or movie players.
> I just need a good, stable and secure platform with zones and ZFS.
You just use text install or you disable gdm service from starting, 
after regular install and that's it.
You benefit with OI with better compatibility with Solaris applications 
and you can also use S10 branded zones I think.
> And capable of being patchable to the latest available secure versions of BASH, SSH, SSL, JAVA and other common Unix OS belongings.
>
> Who is now managing the code?
> Is there a way to organise a roadmap?
> What if some students are put on the project?
>
> -----Oorspronkelijk bericht-----
> Van: Alexander Pyhalov [mailto:alp at rsu.ru]
> Verzonden: donderdag 2 oktober 2014 22:41
> Aan: Discussion list for OpenIndiana
> Onderwerp: Re: [OpenIndiana-discuss] New OI /dev release, release structure
>
> First statement is unfortunately true. To make /dev => /hipster update possible we need
> 1) to republish packages which were not rebuilt since /dev a8 with higher numbers (2014.x)
> 2) republish incorporations so that they either are empty or depend on actual packages
I still do not understand this one. Why killing incorporations is so 
important,
it seems that incorporations definitions could be updated to reflect 
version changes and then go through the testing to make sure everything 
under updated incorporation works together.
That is what incorporations are for, to make sure things work together 
and they are tested before updating it as a whole.
Why there would be any benefit of removing incorporations, but almost 
certain that it would not benefit testing.
I am all for doing testing and keeping incorporations where they are, to 
make system consistent.
Is it truly hard to update a package and update incorporation at the 
same time, while building testing releases, like Hipster's?
> 3) publish neccessary obsoletion / renaming packages
This also needs to be checked and documented, both for recommendations 
what to use instead if some package is removed, how to move current 
configuration to a new one etc.
Packages can not just be removed with no documentation about what to use 
instead in next release.
(And there should be releases and not only package updates)
 From that basic documentation, later before publishing new /dev 
release, documentation for change could be made wider before release, 
telling people what to do administering it.

> 4) test that at least typical text / GUI install can be updated from latest /dev to /hipster.
> Noone volunteered to do it yet.
It was possible before and updating from a8 was almost smooth. And I 
think I reported the moment I figured it is not possible.
Response was not to fix it but to ignore it.
Problem with updating from /dev to Hipster started somewhere before 
releasing Hipster's ISO and 2014.1
That was the best moment to work things out and to make sure that is the 
moment when everyone can update to /hipster. But that moment was not 
used to work things out with smooth update,
and instead we got recommendations to reinstall to Hipster from ISO (?)
when we all know that Hipster development model is unstable to be 
considered something worth for clean install.
I had system that was updating all from Opensolaris 2009.06 with all 
/dev versions, up to Openindiana 151a8 and a9 and now someone will say 
to me update is not possible?

Hipster with it's always changing contents of packages and no revisions 
to jump between different states (versions, like entire etc)
makes quality control and testing almost impossible (figuring out WHEN 
and after what change what problem arise)

I would like to do something with that
but there are also just too many problems with how Hipster now functions 
in every way.

It would need to have numbered revisions between updates, so tester can 
jump to specific state of packages to recreate testing environment 
before and after packages are changed. (entire)

Hipster proved as not suitable for any use but testing and using on 
one's laptop or separate test server.
Problem with Hipster is that it is not meant to be productiion quality 
from the ground up and all philosophy of "let's update a package and see 
will someone compain and report a bug"
works quite well for internal releases/strictly "in between" working 
updates before next /dev release.

Hipster spent too much time going away from Openindiana /dev and it has 
to stop doing so.
> However, I understand that with current development model installing Hipster on production server is some kind of insanity, as we sometimes update software in incompatible ways (major versions update) and sometimes testing is insufficient. It doesn't mean that I forget or don't think about testing, it means that there are no enough users to thoroughly test system (for example today I had to fix python because after last update recompilation with gcc4.8 triggerred specific bug which was found out only when I tried to build python-dependent software in illumos-gate, however, tests, shipped with python were successfully passed (at least, no difference with previous python version)).
It is chicken and the egg problem, but certainly someone has to use it 
before it can get to the next /dev.
And after anough /dev's there should be /release that could have 
/update  and at that moment regular user would choose between /release 
and /dev.

Currently user choose between /hipster2014.1 and /dev
and Hipster has to be compatible with /dev to make things work with 
regular users,
at least complicating things with update with removing incorporations, 
should be talked about.
>
> As for multimedia software, I think SFE deals with this much better now.
> At least
> they shouldn't avoid shipping programs which are illegal in US (different codecs, video/audio players, even wine).
That is what sfe-encumbered is for , to separate sfe that could be used 
(and mirrored) everywhere and packages in sfe-encumbered that must be 
mirrored and hosted outside US,
because of their insane patent laws.