On 07/04/2016 03:11 PM, Nick Coghlan wrote:
On Wed, Jun 29, 2016 at 12:01 AM, Honza Horak <[email protected]> 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. You're free to
introduce such SCL but we cannot expect SCLo SIG will do it for all
collections, since it requires too much resources we simply don't have
currently.
Honza
_______________________________________________
SCLorg mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/sclorg
