On Thu, Oct 3, 2013 at 12:02 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > On Thu, Oct 03, 2013 at 04:14:38AM +0300, Zeeshan Ali (Khattak) wrote: >> On Wed, Oct 2, 2013 at 7:43 PM, Zeeshan Ali (Khattak) >> <zeeshanak@xxxxxxxxx> wrote: >> > On Wed, Oct 2, 2013 at 7:28 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: >> >> On Wed, Oct 02, 2013 at 07:03:36PM +0300, Zeeshan Ali (Khattak) wrote: >> >>> On Fri, Sep 27, 2013 at 12:50 AM, Zeeshan Ali (Khattak) >> >>> <zeeshanak@xxxxxxxxx> wrote: >> >>> > From: "Zeeshan Ali (Khattak)" <zeeshanak@xxxxxxxxx> >> >>> > >> >>> > gnome-continuous is continuous integration system so images produced by >> >>> > it track the git master of all modules and now that GNOME 3.10 is out and >> >>> > many projects have branched for 3.10 maintainance, these images are >> >>> > already 3.12 (3.11 at the moment but thats splitting hair I guess). >> >>> > --- >> >>> >> >>> So how about this patch? >> >> >> >> I have the same concerns about this that I do for the patch you >> >> proposed for Fedora rawhide. Namely that OS in libosinfo have >> >> some implied long term stability, but these are by definition >> >> moving targets. >> >> >> >> I understand your desire to include them though. >> >> >> >> Perhaps we should address this by adding a tag to the XML element >> >> indicating whether an OS is a formal release, or a snapshot ? That >> >> way apps can at least distinguish the two if they have a need to >> >> so, and we can declare that any OS database entry marked as a >> >> "snapshot" is liable to change arbitrarily over time. >> > >> > Sounds good to me, as long as we agree to add 'release-date' (if >> > known) as I'll need that to map a specific image to a specific OS >> > entry in the db in the app. >> >> Oh and talking of release date, isn't a release date in future already >> an indication that this OS entry is a snapshot? Especially if we point >> this out clearly in the docs? If we don't add a separate tag, we'll >> not end up with entries marked as snapshots that are released already >> in case we forget to update them (which I'm sure we will). > > IMHO predicting future release dates is a fool's errand. Every project > I know misses their predicted release dates on a non-negligible number of > occasions. That's why I think it is better to list it as a "snapshot". > I think it is actually a good thing that the libosinfo entry will remain > tagged as "snapshot" release until manually updated, because this is > also non-negligable liklihood we'll need to update URLs and other > metadata. eg, all the fedora repo / ISO URLs change between Beta and > GA, which will invalidate the pre-release XML. Hm.. good points although they seem to apply more to Fedora (and other) snapshots and less to gnome-continuous ones. The latter will unlikely be needing update once a particular GNOME release is out. However I don't think its a very bad idea to handle both the same way so I'll send patch(es) to add this 'snapshot' tag and update these 'future releases' patches to use that. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
