[Libosinfo] [PATCH 2/5] Add an optional 'is-continuous-snapshot' tag to OS entries

[Daniel P. Berrange]

On Mon, Nov 25, 2013 at 02:26:13PM +0000, Zeeshan Ali (Khattak) wrote:
> On Mon, Nov 25, 2013 at 2:11 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> > On Mon, Nov 25, 2013 at 02:01:16PM +0000, Zeeshan Ali (Khattak) wrote:
> >> On Mon, Nov 25, 2013 at 1:49 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> >> > On Thu, Nov 21, 2013 at 05:52:54PM +0000, Zeeshan Ali (Khattak) wrote:
> >> >> Applications can use this to determine if an OS is just a snapshot and
> >> >> not an actual released product yet. For example, gnome-continuous images
> >> >> for development snapshots of GNOME and nightly build ISOs of Fedora etc.
> >> >
> >> > Hmm, hang on, this is getting confusing now.
> >> >
> >> > My understanding was that the GNOME continuous images were officially
> >> > released products, not development pre-release snapshots.
> >>
> >> I think it was the other way around. :)
> >>
> >> * pre-release examples: Fedora X alpha/beta and GNOME 3.9.91/2 ISOs.
> >> * continuous snapshot examples: Fedora nightly ISOs and GNOME continuous images.
> >>
> >> So yeah, they are different and now we have already code/api that
> >> differentiates both.
> >
> > That's not the way I was imagining it though ! When I read 'continuous'
> > I was believing that reflected a GNU Arch/Gentoo style continuous rolling
> > release. The idea is that before now the 'release-date' would implicitly
> > tell you when an OS was "GA" ready, but that isn';t availble for rolling
> > releases, hence the 'is-continuous' tag would help you there. The
> > classification you've described though means we still have the hole
> > around the Arch/Gentoo rolling release model.
> 
> Sorry I don't understand the difference with gnome-continuous case.
> Could you please point it out for me?

An Fedora rawhide/GNOME continuous nightly snapshot is an unstable,
eats babies kind of thing.

An Arch/Gentoo rolling release is positioned as production quality.

Clearly two very different types of OS.

> > I think perhaps we've been looking at this wrong and what we really should
> > have is an enum 'status' field, rather than multiple booleans
> >
> >   <status>snapshot|prerelease|released</status>
> >
> > Where
> >
> >  snapshot == nightly builds / automated code snapshots
> >  prerelease == formal alpha/beta/rc like releases
> >  released == final cut releases
> 
> That is giving the same info to apps as the booleans. We got two
> booleans for snapshot and prerelease and absence of both means a
> 'released' OS.

I think that having it be an enum would be better since it makes
it more explicit / clearer IMHO

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|