On 11/25/2014 10:07 AM, Jim Perrin wrote: > > On 11/25/2014 09:47 AM, Pat Riehecky wrote: >> On 11/25/2014 09:30 AM, Honza Horak wrote: >>> Hi guys, >>> >>> this is related to the new SCL SIG [1], which is supposed to bring SCL >>> development into CentOS, which is supposed to become upstream for >>> Software Collections. >>> >>> I've promised I'd look at how dist-git could look like on CentOS side, >>> since we want to start keeping source code for SCLs under CentOS soon. >>> >>> So, [2] is a proposal -- please, take a look at it, so we have >>> something to start with. Let's see if it is feasible. >>> >>> We can also move it to CentOS wiki, which would be more appropriate >>> place for it, but I cannot figure out a where I have permissions to >>> add some new content to. >>> >>> More information about Software Collections concepts is available at [3]. >>> >>> What next? I think we should gather some feedback on this proposal, >>> try to figure out open questions there. Then we will pick up some >>> software collection and create some PoC build from CentOS dist-git. >>> >>> Regards, >>> Honza >>> >>> [1] http://wiki.centos.org/SpecialInterestGroup/SCLo >>> [2] >>> https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal >>> [3] https://www.softwarecollections.org/en/docs/guide/ >>> _______________________________________________ >>> CentOS-devel mailing list >>> CentOS-devel at centos.org >>> http://lists.centos.org/mailman/listinfo/centos-devel >> My primary concern with [2] is how it integrates with the existing SCLs >> withing git.c.o. [4] > The existing (rhscl)SCL code on g.c.o won't change. This would add new > branches to existing packages, and create some new packages with scl-* > branch names unless they find their way into rhscl as well. The C6, C7 > branch names are protected. > >> As a downstream consumer, I would prefer not to rebuild my workflow. > With this method, you shouldn't have to. > > >> [4] a few quick examples: >> https://git.centos.org/summary/rpms!mysql55-mysql >> https://git.centos.org/summary/rpms!nodejs010-nodejs-mongodb >> https://git.centos.org/summary/rpms!postgresql92-postgresql >> https://git.centos.org/summary/rpms!python33-mod_wsgi >> > As I understand it, these would get a branch name like scl-mysql55 where > the software-collections.org maintainers would have branch level commit > access. Things in the c7 branch would be left untouched. > > Does that help to answer your questions? Does this method impact your > current workflow? > I may be reading it incorrectly, but my reading of [5] has, for example the mysql55 collection, branched off of 'mysql' whereas the existing RHSCL is branched off of 'mysql55-mysql'. Would these repos be under a different "git.c.o Project"? Right now I just track 'c7' and (eventually) 'c6'/'c5'. With the existing RHSCL packages in a 'c7' branch, though they are not built, I guess I'm mostly reaching for something on the RHSCL package repo/nameing/branch/etc as it relates to the SCL SIG. While I know the aim of this SIG right now is just about upstream scl.org, I'm trying to get the big picture as the parts inter-relate. I'm not opposed to workflow adjustment for cleaner repo/branch/namespace/thing on git.c.o, right now we use centos.git.repolist.py from centos-git-common. Pat [5] https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal#Repositories_naming (and following) -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/