[scl.org] Component name in non-RH dist-gits

Mikolaj Izdebski mizdebsk at redhat.com
Tue Feb 17 11:17:38 UTC 2015


On 02/17/2015 08:52 AM, Honza Horak wrote:
> I'm thinking about repositories and branches structure in CentOS a bit
> again.
> 
> Currently, there are two ways how components names and branches are
> maintained in SCL world:
> 
> A) collection name in branch name
> we use component name without prefix in dist-git and branches for
> specific collections internally in RH, so e.g. mariadb has branches for
> mariadb55-*, rh-mariadb100-*, etc..
> 
> B) collection name in dist-git repository name
> For RHSCL RPMs that are automatically imported into
> https://git.centos.org [1], components *use* prefix in repository names
> and static set of branches. For example mariadb55-mariadb component
> includes branches 'master' and 'c7' [1]. This way seems easier for
> dist-git administration and also seems to be preferred way in Fedora [2].
> 
> Since we can always add remote branches in (B) and merge/cherry-pick
> from those as easy as we can in (A), my question is:

Git is very flexible in this aspect. You can have one local repo with
many remotes and vice versa - one remote repo with multiple per-SCL
local repos. You can rename local branches too according to your needs.

> 
> "Are there any practical advantages of (A)?"

One I can think of is that you can easily guess Koji build target from
branch name.

> I don't see any, but I see some advantages of (B) though, since it seems
> to be more consumable to use the same approach (B) in all public repos
> and only use (A) internally only for historic reasons.
> 
> Does it make sense to you as well?
> [no response means yes to me :) ]

I personally slightly prefer A (maybe just because I'm used to it), but
I think that both approaches are good, as long as spec files are named
as they are now. It's important to keep the same names across different
repos for easier merging.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk




More information about the SCLorg mailing list