hi
SIGs are releasing stuff, the Cloud SIG has had a few updates since their initial release, but this content isnt being announced as yet. To work towards this, I am going to plumb in an auto email script that should send out one notice per SIG per day, for days when that SIG has released content. Since the sign, push only runs once a day, it wont be a huge number of emails.
As a test bed, I am going to set this up to send these announcements to the CentOS-Devel list ( this list! ), and if everyone feels the format etc is fine, we can then start sending them to the CentOS-Announce list.
Regards,
On Thu, Nov 26, 2015 at 10:17 AM, Karanbir Singh mail-lists@karan.org wrote:
hi
SIGs are releasing stuff, the Cloud SIG has had a few updates since their initial release, but this content isnt being announced as yet. To work towards this, I am going to plumb in an auto email script that should send out one notice per SIG per day, for days when that SIG has released content. Since the sign, push only runs once a day, it wont be a huge number of emails.
As a test bed, I am going to set this up to send these announcements to the CentOS-Devel list ( this list! ), and if everyone feels the format etc is fine, we can then start sending them to the CentOS-Announce list.
+1
-George
On 26/11/15 10:17, Karanbir Singh wrote:
As a test bed, I am going to set this up to send these announcements to the CentOS-Devel list ( this list! ), and if everyone feels the format etc is fine, we can then start sending them to the CentOS-Announce list.
The first few are going to be hand delivered, with me pasting in the bits generated by the system ( since there is no email path out of there!)
note:
the release id is : CSIG-2015:XXXX to match the format of what we are already doing in centos-announce. Here the XXXX will be a serial starting from 0001 and will run through the calendar year.
There will be one post per day per sig, ie. if there are multiple SRPMS included in the push, they will be summarised into one email. This is a change from how we do the distro updates, where there is an email per srpm ( with a few exceptions, but very few ). Open to change requests on this.
regards,
On 26/11/15 10:40, Karanbir Singh wrote:
the release id is : CSIG-2015:XXXX to match the format of what we are already doing in centos-announce. Here the XXXX will be a serial starting from 0001 and will run through the calendar year.
one problem with this, is that RedHat already allocates numbers in exactly the same manner, ie. were going to conflict on ID's unless everyone always uses the entire id (ie. use CSIG-2015:0001 instead of 2015:0001 ).
One way to fix this might be to add an alpha digit in the second part, eg: CSIG-2015:A001 that keeps the component id part ( 2015:A001 ) unique and usable as the ID.
There will be one post per day per sig, ie. if there are multiple SRPMS included in the push, they will be summarised into one email. This is a change from how we do the distro updates, where there is an email per srpm ( with a few exceptions, but very few ). Open to change requests on this.
One slight complication is that the CentOS Linux 6 and 7 content is marked differently so that people can filter on it with the centos-announce list's filtering option. We got lucky today in that the Cloud SIG only had CentOS Linux 7 content, and virt sig only has CentOS Linux 6 content.
The options we have is : keep posting one per CentOS Linux release, per SIG per day. or Mash the different CentOS Linux releases updates into one email per SIG, this would make it easier to parse for people tracking multiple versions, but would break filters in the announce list for people who only want one release versions content.
thoughts ?
On 11/26/2015 12:14 PM, Karanbir Singh wrote:
On 26/11/15 10:40, Karanbir Singh wrote:
the release id is : CSIG-2015:XXXX to match the format of what we are already doing in centos-announce. Here the XXXX will be a serial starting from 0001 and will run through the calendar year.
one problem with this, is that RedHat already allocates numbers in exactly the same manner, ie. were going to conflict on ID's unless everyone always uses the entire id (ie. use CSIG-2015:0001 instead of 2015:0001 ).
One way to fix this might be to add an alpha digit in the second part, eg: CSIG-2015:A001 that keeps the component id part ( 2015:A001 ) unique and usable as the ID.
There will be one post per day per sig, ie. if there are multiple SRPMS included in the push, they will be summarised into one email. This is a change from how we do the distro updates, where there is an email per srpm ( with a few exceptions, but very few ). Open to change requests on this.
One slight complication is that the CentOS Linux 6 and 7 content is marked differently so that people can filter on it with the centos-announce list's filtering option. We got lucky today in that the Cloud SIG only had CentOS Linux 7 content, and virt sig only has CentOS Linux 6 content.
The options we have is : keep posting one per CentOS Linux release, per SIG per day. or Mash the different CentOS Linux releases updates into one email per SIG, this would make it easier to parse for people tracking multiple versions, but would break filters in the announce list for people who only want one release versions content.
I'd be fine with two separate announces. I expect there will be more and more content different for el6 and el7 in time, as el6 gets older and older.
I'm also thinking how to get a link with additional info there. Maybe having a common link to wiki for every SIGs, which would be used as main page for additional information about the content provided by SIG? In case of SCLo, this page would include links to other pages, where info how to install/use the SCL would be found.
Honza
On 26/11/15 12:30, Honza Horak wrote:
On 11/26/2015 12:14 PM, Karanbir Singh wrote:
On 26/11/15 10:40, Karanbir Singh wrote:
the release id is : CSIG-2015:XXXX to match the format of what we are already doing in centos-announce. Here the XXXX will be a serial starting from 0001 and will run through the calendar year.
one problem with this, is that RedHat already allocates numbers in exactly the same manner, ie. were going to conflict on ID's unless everyone always uses the entire id (ie. use CSIG-2015:0001 instead of 2015:0001 ).
One way to fix this might be to add an alpha digit in the second part, eg: CSIG-2015:A001 that keeps the component id part ( 2015:A001 ) unique and usable as the ID.
There will be one post per day per sig, ie. if there are multiple SRPMS included in the push, they will be summarised into one email. This is a change from how we do the distro updates, where there is an email per srpm ( with a few exceptions, but very few ). Open to change requests on this.
One slight complication is that the CentOS Linux 6 and 7 content is marked differently so that people can filter on it with the centos-announce list's filtering option. We got lucky today in that the Cloud SIG only had CentOS Linux 7 content, and virt sig only has CentOS Linux 6 content.
The options we have is : keep posting one per CentOS Linux release, per SIG per day. or Mash the different CentOS Linux releases updates into one email per SIG, this would make it easier to parse for people tracking multiple versions, but would break filters in the announce list for people who only want one release versions content.
I'd be fine with two separate announces. I expect there will be more and more content different for el6 and el7 in time, as el6 gets older and older.
Seems to be the feeling a few other people shared as well, so for now, lets keep it as one announce per CentOS Linux release.
I'm also thinking how to get a link with additional info there. Maybe having a common link to wiki for every SIGs, which would be used as main page for additional information about the content provided by SIG? In case of SCLo, this page would include links to other pages, where info how to install/use the SCL would be found.
Thats a good idea, we can send a can'd note with each announce, with it being either per SIG, per destination directory or per SRPM. We might need a git repo to store all of those though. Let me look at that.
On 26/11/15 11:14, Karanbir Singh wrote:
One way to fix this might be to add an alpha digit in the second part, eg: CSIG-2015:A001 that keeps the component id part ( 2015:A001 ) unique and usable as the ID.
This looks to be the way to go - Red Hat product / Fedora teams dont seem to go into this space ( eg. A001 ), so were covered there.
Any objections to this ? if not, I'll go ahead and start plumbing in announces.
-
George Dunlap -
Honza Horak -
Karanbir Singh