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@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#Rep... (and following)