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

[Honza Horak]

On 02/17/2015 12:17 PM, Mikolaj Izdebski wrote:
> 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.

It seems CentOS guys are fine with this approach as well, the rpms 
imported into centos won't be actually used for building, we'll be able 
to use either way.

>> 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.

Sure, this will need to be kept.

Honza