[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [scl.org] How to submit patches for SCLs



On Thu, Jul 07, 2016 at 09:13:54AM +0200, Honza Horak wrote:
> On 07/04/2016 03:11 PM, Nick Coghlan wrote:
> > On Wed, Jun 29, 2016 at 12:01 AM, Honza Horak <hhorak redhat com> wrote:
> > > General rule of what goes in is that it always depends on the author of the
> > > particular collection.
> > > 
> > > For collections coming from SCLo SIG group (community), the best thing to do
> > > would be sending pull requests on github as mentioned bellow and contact
> > > this ML if nothing happens (not everybody tracks github appropriately).
> > > 
> > > For collections coming from Red Hat (usually those with rh- prefix), we have
> > > quite strict rule, that we don't want to include anything what is not
> > > included in RHSCL packages. So, what might be more successful strategy for
> > > collections coming from Red Hat is reporting bug to the Red Hat Bugzilla and
> > > increase probability of inclusion by contacting Red Hat Support.
> > 
> > Is there an ETA for when the RHSCL collections will get a proper
> > upstream that accepts patches, rather than just bug reports? (I
> > thought establishing that was part of the purpose of the CentOS SIG)
> 
> It is possible already now. The important thing is that such patches may get
> into a collection that is *different* than the collections shipped by Red
> Hat, but we won't block anybody to introduce such a new collection with for
> example more frequent updates.
> 
> What it means in practice -- say you want python 3.5 collection that is
> following upstream releases more closely than rh-python35 and provides
> patches that are not included in rh-python35 SCL -- then this SCL will need
> to be called differently, say sclo-python35 or nick-python35 or anything
> else following the pattern owner-nameVersion.

What it means in practise -- you will have to rebuild all your dependencies
that worked with rh-python35 because of the owner-nameVersion pattern crept
into RPM dependencies.

Nick, maybe you knew that, just not to be surprised. SCLs, in contrast to base
RHEL, does not allow sharing binary packages.

-- Petr

Attachment: signature.asc
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]