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