On Mon, Nov 25, 2013 at 2:32 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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. Ah ok, thanks. A graphic example helps :) >> > 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 Hmm.. sure. I'll rework the patches then. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
