[oi-dev] IPS repo organisation and versioning

[Bayard Bell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30 May 2011, at 23:25, Alasdair Lumsden wrote:

> Repo wise:
> 
> /release - for the stable releases
> /release-staging - a short-term staging area for us to test updates due to be published to /release, so we don't screw up peoples machines en-masse with untested updates
> 
> /dev - for our public consumption development releases, because we all know end users want bleeding edge desktop stuff.
> /dev-staging - a short-term place where /dev releases get tested, so that, again, we don't screw up peoples machines en-masse with untested stuff
> 
> /experimental - primarily for oi devs, where we put in-progress and known-broken updates for people collaborating on forthcoming features/releases. This would help for longer-term collaborative development of bigger changes.

As for -staging and maybe experimental, I wonder if they should be made fully private, either enforced by IPsec restrictions on depot access or requirement for something like PKI authentication with an Apache front-end (I read about the latter in Oracle docs). As far as most users are concerned, we aren't presenting things that are internal bits of release management. Also, if we're staging things like security fixes through the -staging repos, we don't want to telegraph before making a security announcement.

> This is an increase on the number of repos we have now, and I appreciate there's a maintenance cost, but when we launch stable we will definitely need to stage the updates. /dev-staging is just /dev-il renamed. /experimental is new and requested by a few people who want to work on things that will be unstable for a good few /dev releases.
> 
> Version wise:
> 
> The Oracle build numbers no longer make sense (eg 0.151 aka [snv|oi]_151), so with the forking we have an opportunity to switch to something saner. We've been talking about doing this for ages, but haven't really come up with something. I've had a proposal through from DeanoC which I've tweaked slightly, which I think makes sense for us to do in time for the stable release. I'd appreciate feedback.
> 
> For the first stable release, we could bump the version up to 1.0.0. The next stable release would be 2.0.0. Security and bug fixes would increment the last digit, so 1.0.X, eg 1.0.4.

I'm not sure about the last part, at least if it's a point patch. What's the scope of what's versionised in this way?

Also, an excellent question to consider in the context of what saablover learned the other day from alanc is where else we should provide what I'll call consolidation meta-versioning, which is enforcing versions between components that are built and possibly tested together. Alan explained a number of scenarios where this makes sense, like when you have a number of components that are using private interfaces where everyone needs to be at the same version. There's some very broad and conservative use of consolidation manifests kicking around because there were some reasonable uses cases in ONNV that were blanketed out. Oracle's now pulling them back in a lot of places. Alan's best example is tzdata, which is made consolidation version-consistent with the rest of SUNWcs, even though it's just data that regularly needs to be changed and which the rest of them consume (actually, that reminds me to check what's done with tzdata generally in Illumos, as that stuff changes all the time, not just because of current events but to reflect historical events, like the use of daylight savings during WWII or who took back what territory when and switched over to their metropolitan system, reverting from what the previous occupying power did). There are reasonable arguments for using this outside of absolutely strict dependencies (e.g. so that people aren't mixing and matching things that haven't been tested together, thus churning in bug reports). I think the point I'd underline here is that we can effectively have a series of versioning schemes, so we need to decide what's reflected by the OS version and what's not.

I don't know if that explains anything, so it's something we can talk over on IRC.

Cheers,
Bayard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)

iQIcBAEBAgAGBQJN7PbBAAoJEHm5cBpJ87doz70QAKSctP+QxBTIJWmWq9y6HDmU
p/wABwfPMlKuNP3doW5AUWKrtmQUS1SHc4nsum1M+9E3Z7r+Ys/LPHxDTaeO915c
c1akZPEkFGnDtVoQHor+y6tcoAxTiEpMtjmommGRk5NvVczjsG6D0IN4nh614FsY
bQWRSJ4hUmcwo0DbQvyGaxGcsPsBkNZUCfKp34MtKFJyw5PX5mkI6PTjwa4G1JZR
yHI1uuUOgfF9iNk7BdlFgjOcJCvN4AG1LccLNZ82QBsCCL21Vr/OBIaQU/llzq0j
aUuRzYN4ubopxmkKuFYBuAElUooHIjNSuG9vjNRx5UOyXbM13SsgESlEC8dfCOww
xLHZfOtu1dEd9k9KDieQQSRoBuBkxvJQKrvuZ+6N//UkuUPVLy++b3ORKSwR+kDb
TE4SDNWBgMrHo6Mteom+9/EdUyIWrppd5oyZGGBij2iclt0FSvMharkQ04gh62Mv
JFUxJG76ttm21S5GiOEPr+A9KMLXMQpiHbq6WFzSMznSHEZTWI9aPQJ/Q+U8OWtZ
t+Rxu5pNPF2bdXKbRUdX/8cln54XQUeDmwwcXLfyJjmlKmMmZvlAEHx8D7YUYO1d
gwUjEkSYziB+STzCLOeb1PBw+2P/trVRX6FKh6wWymBIP/b71oIqHnDVorMTmMWc
57MECCjubimZT2Qqa/cs
=iVsQ
-----END PGP SIGNATURE-----