On Oct 24 14:36, Karanbir Singh wrote: > hi, > > On 10/22/2014 03:42 PM, Brian Stinson wrote: > > Hi All, > > > > In the CBS/Infra meeting on Monday we agreed to start a discussion here > > on the mailing list about how to handle "ad-hoc" upstreams. An ad-hoc > > upstream could best be described as a project we would like to ship that > > is developed within the CentOS community (centpkg is one example). > > to be clear, these upstreams are code repos, not dist-git like repos to > host rpm packages; some of these might not even be targetting rpms ( eg. > the test suites that a SIg develops or any scripting that they need, > docs etc would also be included in this ) > > > Developers of an ad-hoc upstream need some extra infra (e.g. a git repo > > for doing active development) in addition to the dist-git repo on > > git.centos.org where the package specs live. > > > > I would like to start the policy and procedure discussion with the > > following proposals: > > > > - Host the ad-hoc development repositories on git.centos.org in separate > > Gitblit projects > > +1 > > > > > - Host the ad-hoc development repositories on Github, linked to the > > CentOS project group > > For projects that want to, we can share namespace under either > github.com/CentOS or /CentOSProject > > > - Host the ad-hoc development repositories someplace else? > > if the target is CentOS and the larger EL ecosystem around it, hosting > the end result git repos on git.centos.org ( or atleast hosting it via a > mirror from somewhere else ) would be the way to go, I think. It also > reduces the barrier to sync releases and dist-git content when needed. > > - KB > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel Another plus for hosting on git.c.o is that it encourages discussion here on the mailing list, instead of fragmenting into multiple streams of communication (as would happen with github pull requests). What are some other examples of projects that would benefit from this workflow? Brian -- Brian Stinson bstinson at ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk