[CentOS-devel] CSIG-2015:0002 Info CentOS 6 VirtulizationSIG Update

Fri Nov 27 09:08:30 UTC 2015
Honza Horak <hhorak at redhat.com>

On 11/26/2015 02:10 PM, Karanbir Singh wrote:
> On 26/11/15 12:21, Honza Horak wrote:
>> On 11/26/2015 12:10 PM, Karanbir Singh wrote:
>>>
>>> CentOS Virtualization SIG Errata and Security Advisory CSIG-2015:0002
>>> Info
>>>
>>> There is an update notification for content released by the CentOS
>>> Virtualisation SIG.
>>>
>>> The following updated files have been uploaded and are currently
>>> syncing to the mirrors:
>>>
>>> CentOS Linux 6 /virt/x86_64/xen/
>>
>> Hopefully this is the test we're supposed to provide feedback..
>>
>> This seems to me unclear for people who are not familiar with mirrors
>> yet, would it be bad to use full URL here? I understand that other
>> mirror URLs will look differently, but that's what users would
>> understand I guess.
>
> Part of the problem with that is - at this point we dont know where
> these packages are going. Let me look into this, it should not be too
> hard to solve.
>
>>
>>> --------
>>> a6dbfb7ffcabf469dec88e0b844f24bd98ab9aef4ae7357d747ac51a5c711bc0
>>> libvirt-python-1.2.15-1.el6.x86_64.rpm
>>>
>>>
>>> Sources: /virt/Source/xen/
>>> --------
>>> 69db6203a08bd35a9032126e9f841b3a031ea42c4342669c973c6e0c9d8b7698
>>> libvirt-python-1.2.15-1.el6.src.rpm
>>> * Tue Jan 06 2015 Johnny Hughes <johnny at centos.org> - 0.600.0-25
>>> - roll in tap2 support for xen
>>>
>>> * Fri May 30 2014 Giuseppe Scrivano <gscrivan at redhat.com> - 0.600.0-24
>>> - Mark RHEL7 as supported (rhbz#1102345)
>>>
>>> * Thu May 29 2014 Giuseppe Scrivano <gscrivan at redhat.com> - 0.600.0-23
>>> - virtinst: by default add USB2 controllers (rhbz#1001999)
>>> - pvpanic device support (rhbz#1101536)
>>
>> Is this just a diff from last released RPM?
>>
>
> That's what I would like to get to. at the moment, its just the latest 3
> entries. There is no real state being stored anywhere. In order to get
> the diff from last-release, either i can just store the entire changelog
> from last time somewhere, and diff -U it, post the difference, or better
> ( really! ) is to store that in a db, and only look at newer entries (
> dates? ) since last release.
>
> The other thing is, that when we do a new release ( eg. an SCL ) - the
> first night's email will include a -lot- of srpms/rpms and their
> changelogs. Every srpm has its changelog posted.

What if the initial release didn't include any changelog and only 
additional releases would? I don't want to make it more complicated to 
do though, so I'm fine with either way.

Honza