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

[Alexander Pyhalov]

Hello.

On 10/03/2014 16:26, Nikola M. wrote:
>> 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.
1) I haven't said about killing incorporations here. I said making them 
empty OR dependent on actual packages.
2) But I honestly don't think that incorporations are necessary in 
Hipster, perhaps, except entire. They were aimed to control version 
numbers of software from different consolidations. But we want to have 
only one consolidation .  If you want to stick to one package version 
just do pkg fix entire after Hipster install. We could avoid publishing 
empty entire after ISO release and so make Hipster behave more like 
/dev. But I'm inclined to publish empty entire to encourage wider testing.

>> 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.

I don't think so. We have a lot of outdated desktop-related software. It 
has sometimes strange dependencies, brings in more outdated software and 
so on. I think that it's good trend to remove something old, unused and 
unmaintained. If someone wants it back, just fix the package to build in 
oi-userland and work on Hipster.

> (And there should be releases and not only package updates)

We are publishing snapshots once per several months.

>  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.

Agree, documentation can be enhanced.

>> 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.

It is not possible now. At least until all our packages has greater 
versions then /dev. /dev now uses  X-0.151.1.9 versions. We have a lot 
of X-0.151.1.8 versions. IPS can't handle this. Also, a lot of 
obsoletion packages were removed during migration from /hipster to 
/hipster-2014.1 repository. Part of them should be republished to allow 
/dev => /hipster update.

> 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)

We have shipped entire with last ISO snapshot. We are going to ship one 
more with new ISO snapshot. However, I agree, there's issue with testing 
- you can't update/downgrade to the state of some particular  date. But 
it's true also for other OSes and distributions. Do you propose to 
update entire on each package update?

> Hipster proved as not suitable for any use but testing and using on
> one's laptop or separate test server.

I successfully use it for my labs. Using something illumos-based on our 
servers is impossible due to hardware issues. But I don't think I would 
persuade my collegues to migrate from Debian to something else even if 
illumos supported our hardware :)

> 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.

Yes, it was created to speed up OI development. I think it partly 
achieved this goal.

> Hipster spent too much time going away from Openindiana /dev and it has
> to stop doing so.

It's easy to go away from someone standing ;) Seriously, I think that 
moving away from legacy consolidations and build systems is a necessary 
task to ease OI development and to lower barrier for new devs.
-- 
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department