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