<html><body>
<p><font size="2" face="sans-serif">My biggest question is how and when do we move things from /hipster to a testing repo (no non-bugfix changes) and from there to a release.</font><br>
<br>
<font size="2" face="sans-serif">It would be nice if at the same time we made the "old" hipster repo the "new" testing repo, give it a month, then duplicate it into stable. (keeping the old one around for testing incase we catch any bugs later, but before the new promotion)</font><br>
<br>
<br>
<tt><font size="2">Andrzej Szeszo <aszeszo@gmail.com> wrote on 01/16/2014 02:03:27:<br>
> <br>
> Hi All<br>
> <br>
> I was wondering if other people had any concerns or questions about<br>
> the proposed versioning scheme?<br>
> <br>
> Cheers,<br>
> <br>
> Andrzej<br>
> <br>
> <br>
> On 13 January 2014 09:34, Andrzej Szeszo <aszeszo@gmail.com> wrote:<br>
> > On 9 January 2014 23:06, Alexander Pyhalov <alp@rsu.ru> wrote:<br>
> ><br>
> >> 1) When new repository is created? Once a quarter? When old one is too big?<br>
> ><br>
> > At least once a year I think. It will be up to us/devs when to create<br>
> > new repo based on the old repo's size or any other condition.<br>
> ><br>
> >> 2) What packages are migrated to the new repository? The latest <br>
> versions of<br>
> >> every package in the last active repository?<br>
> ><br>
> > Yes, The latest versions of packages in the last active repository,<br>
> > but only installable ones. If some packages were obsoleted, we skip<br>
> > them. Same with the renamed packages.<br>
> ><br>
> >> 3) How do we migrate user systems to new repository, let's say from<br>
> >> pkg.openindiana.org/hipster to pkg.openindiana.org/hipster-2014.0 and<br>
> >> further to pkg.openindiana.org/hipster-2014.1 ?<br>
> >> Some self-destructing SMF? We clearly have to force new BE creation on such<br>
> >> shift.<br>
> ><br>
> > After creating new repo, we would upload modded pkg5 to the old repo.<br>
> > It could emit a message with instructions on what to do to switch the<br>
> > repos on "pkg update". Users would be expected to have their systems<br>
> > fully upgraded before switching the repos. I don't think messing with<br>
> > people's publisher configuration would be a good thing to do.<br>
> ><br>
> >> As for spped of operations on current repository, is it possible to change<br>
> >> "pkgrepo rebuild" to "pkgrepo refresh" in Jenkins build jobs? Is <br>
> it safe? Is<br>
> >> speedup significant?<br>
> ><br>
> > We are currently using old-school pkg.depotd --add-content whcih is<br>
> > fairy quick (it takes minutes). pkg.depotd --rebuild takes 1-2h on the<br>
> > current repo. Package server is running quite old version of pkg5. I<br>
> > am not sure pkgrepo refresh is supported by it at all. Long term I<br>
> > would like to server OI hipster package with newer pkg5 bits but<br>
> > didn't have a chance to look at it yet.<br>
> ><br>
> >> Now, about versioning scheme.<br>
> >> 1) I still don't see a clean way to downgrade package with proposed<br>
> >> versioning scheme.<br>
> ><br>
> > I don't think it is possible to perform automatic downgrades with pkg5<br>
> > in general. Not sure if anything has changed in this regard in the<br>
> > updated pkg5 code.<br>
> ><br>
> >> 2) What is a policy for changing PKGREV_COMPONENT? I propose to set it to 0<br>
> >> by default and force people to increment it with every change in <br>
> a component<br>
> >> which affects its functionality (i.e., not just code cleanup). I <br>
> would reset<br>
> >> it to 0 with every package version bump (e.g. php 5.21=> php 5.22), this<br>
> >> will allow us to keep it sane. And I'm not sure that it is a good idea to<br>
> >> use it just to force package rebuild.<br>
> ><br>
> > I 100% agree with what you described.<br>
> ><br>
> >> 3) What will we do with illumos-gate updates? I mean, proposed <br>
> scheme allows<br>
> >> us to do it in a safe way. However, when build machine is <br>
> updated, this will<br>
> >> force illumos-gate packages update (and BE creation) on a user system even<br>
> >> if the user just wants to update, let's say, vim. And when you want just<br>
> >> install security update for php on a server it's a problem if doing so<br>
> >> requires reboot (for BE activation).<br>
> >> I see several oppotunities.<br>
> ><br>
> >> a) We say, that /hipster is a developer's OI version and it's enough if it<br>
> >> just will not allow user to update package to non-functioning state (i.e.<br>
> >> updating php 5.21 to 5.22 is not possible in the same BE if build server<br>
> >> updated illumos-gate-produced packages between times when php 5.21 and 5.22<br>
> >> versions were built). It's not a perfect scenario, but I'm OK with it. It's<br>
> >> much better than allowing user to install php 5.22 in the same BE and to<br>
> >> find out that it is not functioning because of libc version bump.<br>
> ><br>
> >> b) We update illumos-gate on the server once a (month/week/ ??? ) to allow<br>
> >> some period of stability. Let's say, each Saturday, so for more important<br>
> >> servers I can schedule update if necessary for Sunday.<br>
> ><br>
> >> c) We update it by hand on "as strictly necessary" basis <br>
> (perhaps, combining<br>
> >> with once a month/quarter).<br>
> >> Related question...<br>
> ><br>
> >> If I have system/library version A installed on build machine and version<br>
> >> A+N available in server's default repository, will dependent <br>
> packages depend<br>
> >> on version A or on A+N? Can we publish new illumos-gate versions, but hold<br>
> >> build server's version?<br>
> ><br>
> > I like option c), it will only work after using some new versioning<br>
> > scheme though. Currently, incorporation versions are the same between<br>
> > different illumos-gate builds and we would want to "pkg freeze"<br>
> > specific version of illumos-gate incorporation on the build server.<br>
> ><br>
> ><br>
> >> 4) The same question about IPS. As I understand, on each IPS <br>
> update pkg will<br>
> >> require new BE (and IIRC it refuses to install any new package until pkg is<br>
> >> updated).<br>
> >> I expect that pkg5 repository will not change as often as illumos-gate (at<br>
> >> least after some time of initial bug-fixing). However, we should have some<br>
> >> consistent update policy for it.<br>
> ><br>
> > Perhaps we could tinker with pkg5 logic. I don't think new BEs are<br>
> > really required when updating pkg5. It creates backup BEs anyway.<br>
> ><br>
> >> 5) Just a question of taste. Don't you think that<br>
> >> "4.2.45,5.11-0.2014.0.0.0.2476" is too long? I know, 5.11 is a <br>
> sacred number<br>
> >> in Solaris world, but I don't understand why should we have this magic in<br>
> >> version string (for successful migration? Or IPS just will not <br>
> like anything<br>
> >> else?) and not very sure about 0 before year number. (Why not just<br>
> >> 4.2.45-2014.0.0.0.2476 or MAGIC-2014.0.0.0.2476 for system packages?).<br>
> >> I'm just whining and don't have strong opinion on this point :)<br>
> ><br>
> > I don't mind the length of the version myself. The only part I am not<br>
> > sure about is oi-userland git commit number at the very end. Maybe we<br>
> > should store it as an attribute in the manifest itself not in the<br>
> > version string, for example:<br>
> ><br>
> > set name=info.oi-userland.commit-id<br>
> > value=701319a26127991b79cd8b2e7e617e7f03b98fbd<br>
> > set name=info.oi-userland.commit-url<br>
> > value=https://github.com/OpenIndiana/oi-userland/commit/<br>
> 701319a26127991b79cd8b2e7e617e7f03b98fbd<br>
> ><br>
> > 0. in front of the year I left just in case we decide we want to have<br>
> > version 1.0, 2.0, 3.0 in the future. Perhaps I was looking too far<br>
> > into the future. We can drop it for now.<br>
> ><br>
> > ,5.11 bit is internal to pkg5 so can be ignored. You don't normally<br>
> > see it but it is there in the package manifest pkg.fmri.<br>
> ><br>
> > Cheers,<br>
> ><br>
> > Andrzej<br>
> <br>
> _______________________________________________<br>
> oi-dev mailing list<br>
> oi-dev@openindiana.org<br>
> <a href="http://openindiana.org/mailman/listinfo/oi-dev">http://openindiana.org/mailman/listinfo/oi-dev</a><br>
</font></tt></body></html>