I'm about to submit a couple of requests into bugs.c.o to create necessary infrastructure for collections from RHSCL-1.2 at least. But first I want to make sure about the tag and branches names.
Currently we have some testing build tags: scl6-el6-mariadb100-build scl7-el7-mariadb100-build and branches in dist-git (in sclo project): scl-mariadb100-el6 scl-mariadb100-el7 And the SIG has codename 'sclo'.. So, it's kind of messy already in the beginning :)
Thinking about keeping it simple and uniform, what about this way:
Keep 'sclo' as SIG codename to indicate it's combination of SCL on openness :) CBS build tags in format like: sclo6-mariadb100-build sclo7-mariadb100-build and branches in dist-git (in both sclo and rpms projects): sclo6-mariadb100 sclo7-mariadb100
This mail is to check whether we're fine to go this way or if there are some limitations we need to follow.
dist-git and CBS gurus, please, provide your PoV. Thanks!
Honza
Hi,
On 23/02/15 18:13, Honza Horak wrote:> I'm about to submit a couple of requests into bugs.c.o to create
necessary infrastructure for collections from RHSCL-1.2 at least. But first I want to make sure about the tag and branches names.
Currently we have some testing build tags: scl6-el6-mariadb100-build scl7-el7-mariadb100-build and branches in dist-git (in sclo project): scl-mariadb100-el6 scl-mariadb100-el7 And the SIG has codename 'sclo'.. So, it's kind of messy already in the beginning :)
Thinking about keeping it simple and uniform, what about this way:
Keep 'sclo' as SIG codename to indicate it's combination of SCL on openness :)
I am ok, it makes more sense.
CBS build tags in format like: sclo6-mariadb100-build sclo7-mariadb100-build
We need to keep the disttag in the name as agreed from the beginning for all SIGs: sclo6-el6-mariadb100-build sclo7-el7-mariadb100-build (scol7-el7_1-mariadb-build maybe ; However I don't remember if the SIG agreed to have 1 disttag only per distribution policy even for rhscl rebuild; which is the way to go if you ask me :).
The disttag can be some other string not containing major; e.g: .infra.
I need a way to parse it consistently and existing scripts have been written this way.
and branches in dist-git (in both sclo and rpms projects): sclo6-mariadb100 sclo7-mariadb100
Fine with me, centpkg will do the matching between branches and targets. However, I would wait feedback from the git specialists.
thanks,
On 02/23/2015 08:39 PM, Thomas Oulevey wrote:
CBS build tags in format like: sclo6-mariadb100-build sclo7-mariadb100-build
We need to keep the disttag in the name as agreed from the beginning for all SIGs: sclo6-el6-mariadb100-build sclo7-el7-mariadb100-build
OK, understood.
(scol7-el7_1-mariadb-build maybe ; However I don't remember if the SIG agreed to have 1 disttag only per distribution policy even for rhscl rebuild; which is the way to go if you ask me :).
The disttag can be some other string not containing major; e.g: .infra.
I need a way to parse it consistently and existing scripts have been written this way.
There is one piece I'm struggling with (and I'm not sure if that's the same thing you call special disttag for rhscl rebuild). It is how to deal with conflicting NVRs in koji (supposing CBS koji also doesn't allow two build tasks resulting into the same NVR).
When we build some SRPM first in sclo project and then import the same SRPM to rpms project (so we're able to build it from SCM, sign it and release), then koji build will fail, because we already have the same NVR built from SRPM, right?
I'm thinking if we can solve this by disttag, so e.g. every build from SRPM would get something like ".el6.test" and only SCM builds would get ".el6". As far as I understand koji, that would require another build target, right?
Maybe there is some nicer way to handle this or you may convince me we don't need to solve this at all and just handle it with release bumps. (just thinking loudly now)
Honza
On 02/24/2015 08:47 AM, Honza Horak wrote:
On 02/23/2015 08:39 PM, Thomas Oulevey wrote:
CBS build tags in format like: sclo6-mariadb100-build sclo7-mariadb100-build
We need to keep the disttag in the name as agreed from the beginning for all SIGs: sclo6-el6-mariadb100-build sclo7-el7-mariadb100-build
OK, understood.
(scol7-el7_1-mariadb-build maybe ; However I don't remember if the SIG agreed to have 1 disttag only per distribution policy even for rhscl rebuild; which is the way to go if you ask me :).
The disttag can be some other string not containing major; e.g: .infra.
I need a way to parse it consistently and existing scripts have been written this way.
There is one piece I'm struggling with (and I'm not sure if that's the same thing you call special disttag for rhscl rebuild). It is how to deal with conflicting NVRs in koji (supposing CBS koji also doesn't allow two build tasks resulting into the same NVR).
When we build some SRPM first in sclo project and then import the same SRPM to rpms project (so we're able to build it from SCM, sign it and release), then koji build will fail, because we already have the same NVR built from SRPM, right?
I'm thinking if we can solve this by disttag, so e.g. every build from SRPM would get something like ".el6.test" and only SCM builds would get ".el6". As far as I understand koji, that would require another build target, right?
Maybe there is some nicer way to handle this or you may convince me we don't need to solve this at all and just handle it with release bumps. (just thinking loudly now)
I'm also still thinking about destination tags for sclo SIG -- currently there are those two proposed for every elX version: scloX-testing and scloX-release..
And the process (as I understand it) requires rpms first to be tagged into scloX-testing and after it tag those built from SCM into scloX-release.
I'm not sure if the middle step with scloX-testing is required for rpms coming from 'rpms' git project actually, since those should already be tested from 'sclo' git project.
So, can we actually simplify the process and tag into scloX-release right after building from 'rpms' git project?
If not, then I'd propose to have some different tag for not-yet-released rpms from the stable repos (e.g. scloX-candidate)
Then it would work like this: rpms built from 'sclo' git repos will be tagged into scloX-testing rpms built from 'rpms' git repos will be tagged first into scloX-candidate and then into sclX-release on releasing
Thoughts?
Honza
On 02/25/2015 06:14 PM, Honza Horak wrote:
On 02/24/2015 08:47 AM, Honza Horak wrote:
I'm also still thinking about destination tags for sclo SIG -- currently there are those two proposed for every elX version: scloX-testing and scloX-release..
And the process (as I understand it) requires rpms first to be tagged into scloX-testing and after it tag those built from SCM into scloX-release.
I'm not sure if the middle step with scloX-testing is required for rpms coming from 'rpms' git project actually, since those should already be tested from 'sclo' git project.
So, can we actually simplify the process and tag into scloX-release right after building from 'rpms' git project?
If not, then I'd propose to have some different tag for not-yet-released rpms from the stable repos (e.g. scloX-candidate)
Then it would work like this: rpms built from 'sclo' git repos will be tagged into scloX-testing rpms built from 'rpms' git repos will be tagged first into scloX-candidate and then into sclX-release on releasing
Thoughts?
There is also another idea Remi suggested.. It's basically about having 3 repositories:
- centos-scl => downstream of RHSCL, same content, only for CentOS users
- centos-scl-devel / testing => upstream of RHSCL (we need to ensure that NEVR in this repo < previous one) and perhaps additional packages (for CentOS and RHSCL users)
- centos-scl-sig / additional / stable => package NOT in RHSCL. This can be used by CentOS and RHSCL users.
Honza
On 03/04/2015 06:42 AM, Honza Horak wrote:
There is also another idea Remi suggested.. It's basically about having 3 repositories:
centos-scl => downstream of RHSCL, same content, only for CentOS users
centos-scl-devel / testing => upstream of RHSCL (we need to ensure
that NEVR in this repo < previous one) and perhaps additional packages (for CentOS and RHSCL users)
- centos-scl-sig / additional / stable => package NOT in RHSCL. This can
be used by CentOS and RHSCL users.
I like this idea, but I'm not crazy about the name of the last one, as it's not entirely clear what it is. I might suggest centos-scl-sup(plementary). You guys are the SIG. These packages would supplement what exists already.
This would be a good repo for the 500-odd perl module scl packages we've been contacted about as well.
On 03/04/2015 12:56 PM, Jim Perrin wrote:
On 03/04/2015 06:42 AM, Honza Horak wrote:
There is also another idea Remi suggested.. It's basically about having 3 repositories:
centos-scl => downstream of RHSCL, same content, only for CentOS users
centos-scl-devel / testing => upstream of RHSCL (we need to ensure
that NEVR in this repo < previous one) and perhaps additional packages (for CentOS and RHSCL users)
- centos-scl-sig / additional / stable => package NOT in RHSCL. This can
be used by CentOS and RHSCL users.
I like this idea, but I'm not crazy about the name of the last one, as it's not entirely clear what it is. I might suggest centos-scl-sup(plementary). You guys are the SIG. These packages would supplement what exists already.
This would be a good repo for the 500-odd perl module scl packages we've been contacted about as well.
why not just put these in CentOS-Extras/ ? that only has content not otherwise in the distro upstream.
On 03/04/2015 07:10 AM, Karanbir Singh wrote:
On 03/04/2015 12:56 PM, Jim Perrin wrote:
On 03/04/2015 06:42 AM, Honza Horak wrote:
There is also another idea Remi suggested.. It's basically about having 3 repositories:
centos-scl => downstream of RHSCL, same content, only for CentOS users
centos-scl-devel / testing => upstream of RHSCL (we need to ensure
that NEVR in this repo < previous one) and perhaps additional packages (for CentOS and RHSCL users)
- centos-scl-sig / additional / stable => package NOT in RHSCL. This can
be used by CentOS and RHSCL users.
I like this idea, but I'm not crazy about the name of the last one, as it's not entirely clear what it is. I might suggest centos-scl-sup(plementary). You guys are the SIG. These packages would supplement what exists already.
This would be a good repo for the 500-odd perl module scl packages we've been contacted about as well.
why not just put these in CentOS-Extras/ ? that only has content not otherwise in the distro upstream.
This should be sig specific, and requires sig content. I don't think Extras would be a viable solution here.
On 03/04/2015 01:56 PM, Jim Perrin wrote:
On 03/04/2015 06:42 AM, Honza Horak wrote:
There is also another idea Remi suggested.. It's basically about having 3 repositories:
centos-scl => downstream of RHSCL, same content, only for CentOS users
centos-scl-devel / testing => upstream of RHSCL (we need to ensure
that NEVR in this repo < previous one) and perhaps additional packages (for CentOS and RHSCL users)
- centos-scl-sig / additional / stable => package NOT in RHSCL. This can
be used by CentOS and RHSCL users.
I like this idea, but I'm not crazy about the name of the last one, as it's not entirely clear what it is. I might suggest centos-scl-sup(plementary). You guys are the SIG. These packages would supplement what exists already.
This would be a good repo for the 500-odd perl module scl packages we've been contacted about as well.
The workflow as proposed before only included two repos (collections from 1st and 3rd were actually merged in one repo), which would mean this 500-odd perl module collection would be included (after being developed in scloX-testing) into scloX-release. And I'd expect the prefix would actually distinguish it from rh-perl5xx collection.
My main concern with remi's way is how would we create collections depended on RHSCL rebuilds? The collections are separated from their essence anyway, so I don't see a strong reason to separate them into two repos. With one common repo we'd also safe troubles with having one repository enabled, while another is not (en thus seeing broken deps).
What are advantages of separate repos for RHSCL downstream and additional-stable collections?
Honza
On 03/04/2015 02:13 PM, Honza Horak wrote:
On 03/04/2015 01:56 PM, Jim Perrin wrote:
On 03/04/2015 06:42 AM, Honza Horak wrote:
There is also another idea Remi suggested.. It's basically about having 3 repositories:
centos-scl => downstream of RHSCL, same content, only for CentOS users
centos-scl-devel / testing => upstream of RHSCL (we need to ensure
that NEVR in this repo < previous one) and perhaps additional packages (for CentOS and RHSCL users)
- centos-scl-sig / additional / stable => package NOT in RHSCL. This can
be used by CentOS and RHSCL users.
I like this idea, but I'm not crazy about the name of the last one, as it's not entirely clear what it is. I might suggest centos-scl-sup(plementary). You guys are the SIG. These packages would supplement what exists already.
This would be a good repo for the 500-odd perl module scl packages we've been contacted about as well.
The workflow as proposed before only included two repos (collections from 1st and 3rd were actually merged in one repo), which would mean this 500-odd perl module collection would be included (after being developed in scloX-testing) into scloX-release. And I'd expect the prefix would actually distinguish it from rh-perl5xx collection.
My main concern with remi's way is how would we create collections depended on RHSCL rebuilds? The collections are separated from their essence anyway, so I don't see a strong reason to separate them into two repos. With one common repo we'd also safe troubles with having one repository enabled, while another is not (en thus seeing broken deps).
What are advantages of separate repos for RHSCL downstream and additional-stable collections?
I got the idea about 3rd repo in the end and this is the new workflow proposal: https://www.redhat.com/archives/sclorg/2015-March/msg00021.html
I'd be glad for any feedback..
So, having this changed workflow on my mind, the branches/tags set becomes more complicated... Let's see (using 'rhscl' for identifying collections that are part of RHSCL -- not sure how much it will confuse users):
final tags (and repositories): sclo6-release sclo6-testing sclo7-release sclo7-testing sclo6-rhscl-release sclo6-rhscl-testing sclo6-rhscl-future sclo7-rhscl-release sclo7-rhscl-testing sclo7-rhscl-future
build tags for e.g. collection rh-mariadb100: sclo6-el6-rh-mariadb100-build sclo7-el7-rh-mariadb100-build sclo6-el6-rhscl-future-rh-mariadb100-build sclo7-el7-rhscl-future-rh-mariadb100-build (We need to keep the disttag (el6, el7) in the name as agreed from the beginning for all SIGs)
build targets: sclo6-el6-rh-mariadb100 sclo6-el6-rh-mariadb100-rhscl-future sclo7-el7-rh-mariadb100 sclo7-el7-rh-mariadb100-rhscl-future
git branches under sclo/ project: sclo6-rh-mariadb100 sclo7-rh-mariadb100
git branches under rpms/ project: sclo6-rh-mariadb100 sclo7-rh-mariadb100
Again, will be glad for any feedback for this..
Honza
On 03/11/2015 05:05 PM, Honza Horak wrote:
On 03/04/2015 02:13 PM, Honza Horak wrote:
On 03/04/2015 01:56 PM, Jim Perrin wrote:
On 03/04/2015 06:42 AM, Honza Horak wrote:
There is also another idea Remi suggested.. It's basically about having 3 repositories:
- centos-scl => downstream of RHSCL, same content, only for CentOS
users
- centos-scl-devel / testing => upstream of RHSCL (we need to ensure
that NEVR in this repo < previous one) and perhaps additional packages (for CentOS and RHSCL users)
- centos-scl-sig / additional / stable => package NOT in RHSCL. This
can be used by CentOS and RHSCL users.
I like this idea, but I'm not crazy about the name of the last one, as it's not entirely clear what it is. I might suggest centos-scl-sup(plementary). You guys are the SIG. These packages would supplement what exists already.
This would be a good repo for the 500-odd perl module scl packages we've been contacted about as well.
The workflow as proposed before only included two repos (collections from 1st and 3rd were actually merged in one repo), which would mean this 500-odd perl module collection would be included (after being developed in scloX-testing) into scloX-release. And I'd expect the prefix would actually distinguish it from rh-perl5xx collection.
My main concern with remi's way is how would we create collections depended on RHSCL rebuilds? The collections are separated from their essence anyway, so I don't see a strong reason to separate them into two repos. With one common repo we'd also safe troubles with having one repository enabled, while another is not (en thus seeing broken deps).
What are advantages of separate repos for RHSCL downstream and additional-stable collections?
I got the idea about 3rd repo in the end and this is the new workflow proposal: https://www.redhat.com/archives/sclorg/2015-March/msg00021.html
I'd be glad for any feedback..
Still no feedback?
Small update in the future RHSCL workflow: https://www.redhat.com/archives/sclorg/2015-March/msg00030.html
Honza
So, having this changed workflow on my mind, the branches/tags set becomes more complicated... Let's see (using 'rhscl' for identifying collections that are part of RHSCL -- not sure how much it will confuse users):
final tags (and repositories): sclo6-release sclo6-testing sclo7-release sclo7-testing sclo6-rhscl-release sclo6-rhscl-testing sclo6-rhscl-future sclo7-rhscl-release sclo7-rhscl-testing sclo7-rhscl-future
build tags for e.g. collection rh-mariadb100: sclo6-el6-rh-mariadb100-build sclo7-el7-rh-mariadb100-build sclo6-el6-rhscl-future-rh-mariadb100-build sclo7-el7-rhscl-future-rh-mariadb100-build (We need to keep the disttag (el6, el7) in the name as agreed from the beginning for all SIGs)
build targets: sclo6-el6-rh-mariadb100 sclo6-el6-rh-mariadb100-rhscl-future sclo7-el7-rh-mariadb100 sclo7-el7-rh-mariadb100-rhscl-future
git branches under sclo/ project: sclo6-rh-mariadb100 sclo7-rh-mariadb100
git branches under rpms/ project: sclo6-rh-mariadb100 sclo7-rh-mariadb100
Again, will be glad for any feedback for this..
Honza _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 16 March 2015 at 06:22, Honza Horak hhorak@redhat.com wrote:
On 03/11/2015 05:05 PM, Honza Horak wrote:
I got the idea about 3rd repo in the end and this is the new workflow proposal: https://www.redhat.com/archives/sclorg/2015-March/msg00021.html
I'd be glad for any feedback..
Still no feedback?
Small update in the future RHSCL workflow: https://www.redhat.com/archives/sclorg/2015-March/msg00030.html
Honza
Hi, I have looked over the proposals and they look good. At this point, I would say it is time to move beyond conjecture to a working model to figure out where humans are going to break it :).
On 03/16/2015 08:45 PM, Stephen John Smoogen wrote:
On 16 March 2015 at 06:22, Honza Horak <hhorak@redhat.com mailto:hhorak@redhat.com> wrote:
On 03/11/2015 05:05 PM, Honza Horak wrote: I got the idea about 3rd repo in the end and this is the new workflow proposal: https://www.redhat.com/__archives/sclorg/2015-March/__msg00021.html <https://www.redhat.com/archives/sclorg/2015-March/msg00021.html> I'd be glad for any feedback.. Still no feedback? Small update in the future RHSCL workflow: https://www.redhat.com/__archives/sclorg/2015-March/__msg00030.html <https://www.redhat.com/archives/sclorg/2015-March/msg00030.html> HonzaHi, I have looked over the proposals and they look good. At this point, I would say it is time to move beyond conjecture to a working model to figure out where humans are going to break it :).
Exactly. I've thought about what our chances are without authtag: http://lists.centos.org/pipermail/centos-devel/2015-March/013029.html
and hopefully we'll find some plan what may be done even now on tomorrow's meeting: http://lists.centos.org/pipermail/centos-devel/2015-March/013030.html
Honza
On 03/04/2015 01:42 PM, Honza Horak wrote:
On 02/25/2015 06:14 PM, Honza Horak wrote:
On 02/24/2015 08:47 AM, Honza Horak wrote:
I'm also still thinking about destination tags for sclo SIG -- currently there are those two proposed for every elX version: scloX-testing and scloX-release..
And the process (as I understand it) requires rpms first to be tagged into scloX-testing and after it tag those built from SCM into scloX-release.
I'm not sure if the middle step with scloX-testing is required for rpms coming from 'rpms' git project actually, since those should already be tested from 'sclo' git project.
So, can we actually simplify the process and tag into scloX-release right after building from 'rpms' git project?
If not, then I'd propose to have some different tag for not-yet-released rpms from the stable repos (e.g. scloX-candidate)
Then it would work like this: rpms built from 'sclo' git repos will be tagged into scloX-testing rpms built from 'rpms' git repos will be tagged first into scloX-candidate and then into sclX-release on releasing
Thoughts?
There is also another idea Remi suggested.. It's basically about having 3 repositories:
centos-scl => downstream of RHSCL, same content, only for CentOS users
centos-scl-devel / testing => upstream of RHSCL (we need to ensure
that NEVR in this repo < previous one)
Do we really? I understand that repo more like rawhide in Fedora and it feels correct to me to update collections as soon as this testing repository is enabled.
Not speaking about technical aspect, that would probably require to set epoch in every package in RHSCL, right?
Honza
and perhaps additional packages (for CentOS and RHSCL users)
- centos-scl-sig / additional / stable => package NOT in RHSCL. This can
be used by CentOS and RHSCL users.
Honza _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Feb 23 18:13, Honza Horak wrote:
I'm about to submit a couple of requests into bugs.c.o to create necessary infrastructure for collections from RHSCL-1.2 at least. But first I want to make sure about the tag and branches names.
Currently we have some testing build tags: scl6-el6-mariadb100-build scl7-el7-mariadb100-build and branches in dist-git (in sclo project): scl-mariadb100-el6 scl-mariadb100-el7 And the SIG has codename 'sclo'.. So, it's kind of messy already in the beginning :)
Thinking about keeping it simple and uniform, what about this way:
Keep 'sclo' as SIG codename to indicate it's combination of SCL on openness :)
+1 from me on this. It makes sense to use the actual sig codename.
CBS build tags in format like: sclo6-mariadb100-build sclo7-mariadb100-build and branches in dist-git (in both sclo and rpms projects): sclo6-mariadb100 sclo7-mariadb100
In the client tools, there shouldn't be anything that would hold this up. As long as we remain consistent we can make the mappings work.
This mail is to check whether we're fine to go this way or if there are some limitations we need to follow.
dist-git and CBS gurus, please, provide your PoV. Thanks!
Honza
Is your proposal to rename the existing mariadb tags and git branches?
--Brian
On 02/23/2015 08:54 PM, Brian Stinson wrote:
On Feb 23 18:13, Honza Horak wrote:
I'm about to submit a couple of requests into bugs.c.o to create necessary infrastructure for collections from RHSCL-1.2 at least. But first I want to make sure about the tag and branches names.
Currently we have some testing build tags: scl6-el6-mariadb100-build scl7-el7-mariadb100-build and branches in dist-git (in sclo project): scl-mariadb100-el6 scl-mariadb100-el7 And the SIG has codename 'sclo'.. So, it's kind of messy already in the beginning :)
Thinking about keeping it simple and uniform, what about this way:
Keep 'sclo' as SIG codename to indicate it's combination of SCL on openness :)
+1 from me on this. It makes sense to use the actual sig codename.
CBS build tags in format like: sclo6-mariadb100-build sclo7-mariadb100-build and branches in dist-git (in both sclo and rpms projects): sclo6-mariadb100 sclo7-mariadb100
In the client tools, there shouldn't be anything that would hold this up. As long as we remain consistent we can make the mappings work.
This mail is to check whether we're fine to go this way or if there are some limitations we need to follow.
dist-git and CBS gurus, please, provide your PoV. Thanks!
Honza
Is your proposal to rename the existing mariadb tags and git branches?
Yes, if it is possible -- but only in case it makes no big trouble, which I'm not able to evaluate.
Honza
On 02/24/2015 12:50 AM, Honza Horak wrote:
Honza
Is your proposal to rename the existing mariadb tags and git branches?
Yes, if it is possible -- but only in case it makes no big trouble, which I'm not able to evaluate.
The branches and tags you should have rights to change. If you need to adjust the repo name itself, I can do that for you with a ticket on bugs.centos so I know what you'd like to have.
-
Brian Stinson -
Honza Horak -
Jim Perrin -
Karanbir Singh -
Stephen John Smoogen -
Thomas Oulevey