[oi-dev] [HEADS UP] Userland incorporation

[Nikola M]

On 10/ 9/15 10:53 AM, Alexander Pyhalov wrote:
>> Great,
>> Isn't the point of 'entire' to also depend on illumos-gate version 
>> and kvm?
>>
>
> No. I don't want to speak about entire "point", but
> a) I don't want to incorporate llumos-gate versions and tie them to 
> userland versions. Doing so we'll make illumos developers life harder, 
> and it's I think most valuable OI users.

This is what makes an distribution revisions,
exactly tighting up illumos with userland i what distributions are all 
about.

As you said, developers can not use entire or userland consolidations if 
they want other versions of the packages, so I don't see how tightng 
illumos with userland by default would make illumos dev's life harder?
It woudl make testing much easier because one can put the whole system 
in exact state when some bug appeared and analyze with changing packages 
versions afterwards, what change causes it.
If same tags exist in sources as in binary releases , as discussed in 
other thread,
then pinpointing bug introduction could be straigthforward and more easy.

> b) We already have osnet incorporation and you use it in the same way. 
> Entire depending on osnet doesn't make any sense as you can't install 
> system without installing osnet.

Entire requiring exact osnet is what OS distribution is again all about.
To have any stable or supported release, OS distribution (OI) can not 
always just chase the newest OsNet.
Also to fulfill licensing requirements, OsNet needs to be build from 
local copy of the sources, too
(even if they are refreshed every time OsNet changes to be on bleedeing 
edge)  ,
so using entire to pinpoint to exact sources of exact binaries is an 
easy way of fullfiling that requirement.

It basically wouldn't change anything for Hipster, it would always chase 
newest as before, just giving ability to have sane update 'entire' 
numbers one testing it can jump to
and developers should know how not to depend on entire...

>
>> So that user can set exact state of all system at a present time if
>> testing for regressions?
>
> You can do it choosing necessary userland incorporation date and osnet 
> incorporation date.

If OI hipster is made of osnet and userland then why not also have 
entire to say it exists.
Can I do that from IPS packaging on user side and how?

>
>> it is step in right direction so to say.
>>
>> But I have some questions:
>> I am still not understanding how to figure what package is part of what
>> incorporation?
>
> The following consolidations are used to build      OI Hipster:
> illumos-gate - the base system packages constrained by 
> osnet-incorporation,
> oi-userland, the main one, everything besides Solaris-derived specific 
> software should live here, packages are constrained by 
> userland-incorporation,
> slim_source - installer, packages are constrained by 
> install-incorporation,
> pkg5 - IPS.

In my view, entire should depent on exact version of all incorporations 
that OI hipster is made from,
so one can put the system in exact state if needed.
>
>>
>> When Jenkins is is updating illumos-gate or some package is updated in
>> oi-userland, why when changes are selected to view, they are mixed in
>> jenkins, so illumos-gate change and oi-userland changes display same
>> changes?
>
> Because illumos-gate Jenkins instance monitors oi-userland and uses 
> oi-userland component to build illumos-gate. In fact, it is 
> oi-userland job, just tuned to build only illumos-gate and kvm packages.
>
>> I pretty much dont' understand Hipster layout.
>>
>> Where and how changes in OI Hipster are announced? And where are they
>> made available before actually making changes, since I see changes in
>> hipster just appear and are published without previously knowing 
>> about it?
>> Is there some sort of planning page where people can announce what they
>> are working on and what they plan to integrate and when?
>
> There's IRC and mailing list. You can always create pull request and 
> we will integrate it after review.

This process (is there any process but personal preference of doing 
things?)
  is not that visible and all is seen outside as an activity is update 
appearing and OI source repositories not changing, discontinuation with 
/dev (that is changing I hope) and all that puts feeling of project not 
alive to newcomers.

Process is not visible and things sort of does not happen' in public 
enough for larger audience that should be harvested for newcomers and 
contributors.

If there is some planning that should be at least on Wiki ,
together with plans and explanations etc. (before things happen) and I 
think they should be visible on the OI site. That also depends on 
requirement of having building sources on OI servers, too.


>
>>
>> There is also question of backing down package versions to previous
>> versions if new one didn't work/passed testing. Currently as Iknow there
>> is no way to get back to the system state with previous package version
>> after updating package version.
>> Isn't that is what comlicated package version names on the left side of
>> version number were about, to enable changing package version number and
>> have real upstream package number coming after that as an info?
>
> No, it was about creating numbering scheme which would allow to take 
> into account component revision and different release numbers. It 
> doesn't allow to downgrade package. I have mixed feeling about hiding 
> actual package versions behind release numbers and of course don't 
> want to change current scheme without serious reasons.

Reason to have versions behind release numbers is when one strive to 
have releases to be used in production and maintained inside the release.
The key point here is that OI hipster can not stay forever 
out-of-production and with snapshots releases that are actually not 
releases.

Ability to get versions of packages back is NOT that important for major 
releases where one have one version of package that applies patches to 
during support cycle of an release.

Ability to get back  previous versions of packages IS important to 
fast-changing rolling-release, so hiding versions of packages back 
behind release version is more important for hipster.
If one can not undo package that is updated in hipster and get it back 
to previously working version, then it hinders freedom of testing new 
things in hipster.