On 3/5/19 7:52 AM, Fabiano Fidêncio wrote: > On Tue, 2019-03-05 at 13:48 +0100, Fabiano Fidêncio wrote: >> On Tue, 2019-03-05 at 13:22 +0100, Fabiano Fidêncio wrote: >>> On Fri, 2019-03-01 at 18:41 -0500, Cole Robinson wrote: >>>> This series adds: >>>> >>>> * centos5 entries >>>> * centos6 <tree> data >>>> * scientificlinux 5.X >>>> * scientificlinux 6.X >>>> * scientificlinux 7.X >>>> >>>> No iso data is added, just URLs. I'm trying to get osinfo-db to >>>> have >>>> all the treeinfo coverage that virt-install has. >>> >>> Cole, in the general the series look good (apart from one change >>> that >>> has to be for "Add scientificlinux-7.X". >>> >>> There's one thing that I'm interested to know, though: >>> - Is x.y considered EOL whenever x.(y+1) is released? I mean, will >>> 7.6 >>> be considered EOL whenever 7.7 is released? If so, we'd also have >>> to >>> add the EOL to the 7.x entries. >>> >>> Anyways, for patches #1 to #5: >>> Reviewed-by: Fabiano Fidêncio <fidencio@xxxxxxxxxx> >> >> Actually, let me take my "Reviewed-by" back. >> Please, take a look at 5cac22bc68[0]. >> >> There, the commit message states: >> centos: Remove URLs pointing to vault.centos.org >> >> As vault.centos.org doesn't keep any ISO anymore, let's just remove >> them from our db. >> >> Along with the URLs removal, let's remove together the tree's as >> those >> can't be accessed without a valid URL. >> >> Removing all the vault.centos.org URLs matches with the >> recommendation >> given by CentOS folks in #centos-devel: >> "so in short, if some program links to vault, it's most likely not a >> good idea and may not even work" >> >> [0]: >> https://gitlab.com/libosinfo/osinfo-db/commit/5cac22bc6852d56988ff4be090551c5ec2f3f108 >> >> So, I guess the path to take is to drop #1 and #3. > > Errr, dropping the URLs from #1 and #3, but keeping the tree/treeinfo. > ACK from me, though what was centos reasoning for not pointing to vault.centos.org tree URLs? Those have been stable for years in my experience. I can understand if they don't want those advertised but it's unclear why the comment suggests it might not work - Cole _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
