[CentOS-devel] Upcoming changes to git.centos.org are now in staging

[Pat Riehecky]

On 10/26/2018 08:53 AM, Jim Perrin wrote:
> For right now, I prefer not to. One of the goals for SIGs (that we
> admittedly haven't done a good in achieving) was to promote the
> collaboration between SIGs and the sharing of packages. While copr can
> handle repo dependencies as you point out, it also tends to promote
> repository isolation. You can see this in the fact that there are a
> number of the same package repos built by different people in the Fedora
> copr setup.

I've got a kind of half formed view in my head, so this may be jumbled 
up....

On www.softwarecollections.org there are different kinds of 
policy/project things.  If the COPR moved a bit in that direction with 
some sort of "rational types" and review required for "non-personal 
types", this could help reduce the fragmentation a bit.  (For what it's 
worth I'm super happy with the SCL.org website as a whole UI).  I think 
this could really help promote the SIG as "The Place" to get certain things.

The "project types" might also provide a clean way for proto SIGs to 
privately play around while they sort things out.

In theory the "project types" could provide a hint to folks "Hey I see 
you are building AWESOMEPACKAGE for RELEASE, did you know we've got an 
Approved group that is building AWESOMEPACKAGE for RELEASE over here".

Also having the SIGs located up there could help drive the special 
interest development and then re-merge (similar to Neal's comments).  I 
feel like this could be handy for Fedora but can't think of a good 
example.....

The builtin support for project docs via the "Overview" tab makes a 
clean place to put some items.  Might be simpler than giving people 
rights to https://wiki.centos.org/SpecialInterestGroup/{SIGNAME}

 From a larger unification standpoint this would help simplify searching 
a bit.  Right now there are a few different places to look for 
packages.  Merging the SIGs into COPR would reduce the locations and 
help folks who search before making a COPR repo see what SIGs are out there.

It would also eliminate the need to maintain CBS and sort out the 
occasional package version collisions.  CBS currently shows 1523 Koji tags.

Free support for Modularity is a big bonus.

>
> I'd prefer putting a bit more time (and guidance from Rich) into better
> leadership and SIG work, before trying to achieve the same goal via a
> different tool. I'd like to give time for pull requests and automatic
> builds from pagure->cbs to get into SIG workflows and see what impact
> that has first.
>
>
>
> On 10/26/18 6:11 AM, Pat Riehecky wrote:
>> Larger scale question: With this merge would it make sense to evaluate
>> copr for CentOS SIGs?  It has native support for "This repo depends on
>> this other repo".  Fedora DNF has a copr plugin which could be useful in
>> prep for RHEL8.
>>
>> Pat
>>
>> On 10/25/2018 11:25 AM, Jim Perrin wrote:
>>> In August, the CentOS Project and Fedora announced the intention to
>>> combine their dist-git sources, and since then Fabian Arrotin of CentOS
>>> and Patrick Uiterwijk of Fedora have worked to make that happen. Last
>>> week at the CERN dojo, they demonstrated this work, and today we’d like
>>> to welcome community testing of it. We’ll be keeping this content
>>> updated, so you'll be able to continue to track sources appropriately.
>>>
>>> You can help us by testing the new system, providing feedback, and
>>> contributing additional tooling to help improve the overall state of the
>>> project.
>>>
>>>
>>> Structure:
>>>
>>> Currently git.stg.centos.org and src.stg.fedoraproject.org are linked
>>> via RepoSpanner[1], and sharing common repositories. Packagers for the
>>> roughly 6700 common packages in both communities will see the additional
>>> branches..
>>>
>>> For the Fedora community, there should be no changes required for the
>>> day to day operation of dist-git or packaging.
>>>
>>> CentOS community members will note that the platform change to pagure
>>> brings a variety of new features, including a new API[2] , a new UI,
>>> pull requests, and issue tracking. The current tooling for CentOS
>>> sources will continue to work (after updating to the staging server) and
>>> we plan to add support for tooling for centpkg, which would mirror the
>>> functionality found in fedpkg.
>>>
>>> In the coming weeks we'll be putting out  documentation around the
>>> expected uses for pull requests, and the issue tracking features within
>>> pagure, as we don't intend it to replace bugs.centos.org.
>>>
>>>
>>>
>>> Permissions and ownership:
>>>
>>> There are protections enabled to prevent either community from
>>> accidentally overwriting code from the other, so only CentOS community
>>> members will be able to push to c#-* branches, while only Fedora
>>> community members can push to f#*/epel#* branches. With the new dynamic
>>> ACL validation in place, CentOS SIG members will automatically get the
>>> rights to push on their specific branches.
>>>
>>> While the repositories and content are shared between the communities,
>>> authentication is not. To push to c# branches, you will have to
>>> authenticate against accounts.centos.org. Similarly Fedora community
>>> members will continue to authenticate against accounts.fedoraproject.org.
>>>
>>>
>>> 1.
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_repoSpanner_repoSpanner&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=tN30jLNQUA_3ObunvFtze7SRlSuf6Fb7hw_-u1ICuEE&s=K4ptnci4T_l8sefxynoicf9f4prudYeY-A95N8vnF84&e=
>>>
>>> 2.
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.stg.centos.org_api_0_&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=tN30jLNQUA_3ObunvFtze7SRlSuf6Fb7hw_-u1ICuEE&s=u-a90AeWQ2jHORuxBGzzpatTc5YtTNzzJJUt6-kybOc&e=
>>>
>>>
>>>
>>>

-- 
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org