[CentOS-devel] Policy for Ad-Hoc Upstreams: Development Hosting

[Brian Stinson]

On Oct 22 23:19, Nico Kadel-Garcia wrote:
> On Wed, Oct 22, 2014 at 10:42 AM, Brian Stinson <bstinson at ksu.edu> 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).
> 
> Is there some reason the work cannot or should not go into getting the
> packages into Fedora and EPEL? I realize there's a much more
> professional relationship with RHEL now that git.centos.org is the
> RHEL 7 publication repo, and that EPEL will not publish tools that
> overlap with RHEL upstream and thus overlap with CentOS, for a lot of
> very good reasons.
> 
> > 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
> >
> > - Host the ad-hoc development repositories on Github, linked to the
> >   CentOS project group
> >
> > - Host the ad-hoc development repositories someplace else?
> >
> > Thanks!
> > Brian
> 
> It takes some work if you're overlapping the core OS packages, work
> that I'm sure CentOS developers are familiar with. I personally
> publish toolsl for that for RT version 4 and Samba version 4 at
> https://github.com/nkadel/.

I can't speak for the others who were looking for this sort of workflow,
but it makes sense to host upstream development (that is, the day-to-day
commits) for Centpkg and centos-packager someplace the CentOS project
controls. 

Originally I was in favor of having the stuff we develop go in separate
projects on git.c.o but that may end up being extra administrative work
for the infra team. 

Brian 

--
Brian Stinson
bstinson at ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk