[CentOS-devel] [rh-scl] Proposal for CentOS dist-git design

On 11/26/2014 07:51 AM, Remi Collet wrote:
> Le 25/11/2014 09:05, Honza Horak a écrit :
>> Hi guys,
>
> Hi,
>
>> this is a draft for CentOS dist-git design I put together from various
>> notes/ideas. It still needs to polish, so it will probably be changing
>> in but I wanted to share it as soon as possible to gather feedback soon
>> and incorporate your ideas.
>>
>> https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal
>
> First, sorry for stupid questions, but it seems I still haven't
> understand the goal, what we want to fix, and how.

Remi, thanks for them! For some I had no answer yet, so I added them to 
the wiki with some just figured out answer:
https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal#FAQ

Also CC'ing centos-devel list, since these are all questions we need to 
answer publicly.

So, what we want to fix here..
CentOS is a platform used by huge amount of users, who e.g. develop apps 
for RHEL. Missing SCLs in CentOS is then problem for those users, 
because they cannot develop apps using SCLs. I guess there are no doubts 
SCLs are needed in CentOS.

Then, why move *development of the future SCLs* to CentOS and not 
rebuild RHSCL there downstream? There are RH projects (like OpenShift) 
that also need to have community version of the product available 
publicly for all, so they started to use CentOS as their development 
platform. That means fixes land in git.centos.org first, where everybody 
can test, and community can see code that will land in RH in the future. 
So they build community on CentOS.

Given there are already projects using CentOS as development platform 
and given users use CentOS as development platform, we see it as great 
opportunity to build community around SCLs there as well, which is what 
SCLs is missing.

Also, it makes sense to have a common platform where upstream 
development of RH layered products takes place and where products may 
interact. We consider CentOS to be this platform now.

>
> 	"... where future upstream development of Software Collections
> 	 will take place"
>
> So, if I understand correctly, if I want to create a "php56" collection,
> I should be able to do it in git.centos.org ?

Yes.

> Where the packages will go (which repository) ?

My proposal is to use one repository on CentOS side for all collections. 
However, this will be a different repository than the one for rebuilt 
RHSCL collections (if there ever will be such a repository).

> How user will see the difference between "stable" packages and
> "development" packages ?

I'm not sure yet, but there can be two repositories. One repository with 
stable downstream rebuild of RHSCL, another with SCLs that include fixes 
above RHSCL and have quality compared to Fedora.

> If, at some time, RH provides a "php56" collection, this can be pulled
> from this one. But what will happen next to earlier packages ?

Nothing, it will stay, new patches will still be landing there before 
they land in RHSCL.

> Will the ACL on the package stay the same ?

ACLs were not consulted yet.

> About koji setup:
>
> Which repository/tags will be enabled in each target ?

I expect only CentOS and already built SCLs will be available.

> Especially, will EPEL be available, or some replacement ?

I don't think so, why EPEL?

> Will the SCL-SIG be able to add additional packages in existing
> collections ?

If you mean already released collections, we haven't consulted what will 
happen with them, just that sources are already available for CentOS and 
we'll let CentOS community to build them. For new collections, which are 
subject of this proposal, it will be possible.

> Exemple : for now, Fedora is upstream for RHEL, packages are then split
> between RHEL and EPEL (short way to describe what happen).
>
> How can we manage, p.e. php-mcrypt (huge user demand) in this
> configuration ? (part of php in Fedora, and php-extras in EPEL).

Not sure what are you asking for. php-mcrypt will be part of php56 
collection for instance, but I probably did not understand the question.

>>From my point of view, there should be a clear definition of "upstream"
>
> Old:
> 	"Fedora is upstream of RHEL"
> New:
> 	git.centos.org is upstream of RHSCL,
> 	in one "experimental" repository
> 	(not yet in RHSCL)

Yes.

> Old:
> 	"RHEL is upstream of CentOS"
> New:
> 	git.centos.org receive clone copy of RH content
> 	in one "production" repository.
> 	(clone of RHSCL)
>
> 	git.centos.org produce more content
> 	in one "additional" repository
> 	(like EPEL for RHEL)

Yeah, the whole point is that CentOS won't be only downstream for all RH 
products any longer. It will stay downstream for RHEL, but upstream for 
some other projects.

> I think we probably even need more git or more branches, not a single one)

Git will be similar to what we have internally, one repository per 
component and branch for every "combination of CentOS and collection" 
where it makes sense. But it is already mentioned in the proposal.

>
> Regards,
> Remi.
>
>
>
> P.S. are we trying to kill Fedora ?

I hope not :) Just SCLs don't bring so much value for Fedora users, 
since they already have their packages in latest versions there. That 
does not mean SCLs are not usable there, I'd love to see SCLs in Fedora 
still; just we focus more on CentOS now because it will solve more 
issues for more users currently.

Honza