Software Collections SIG
SIG Status: Approved
Board Member Helping Bootstrap: JimPerrin
The Software Collections SIG will provide an upstream development area for various software collections and related tools. Developers can build on and extend existing SCLs, so they don't need to re-invent the wheel or take responsibility for packaging unnecessary dependencies.
Goals
Act as upstream git repository for [http://www.softwarecollections.org SoftwareCollections.org]
- Work with developers to accept contributions for newer software collections.
- Establish release management duties to act as gateway to build/sign/distribute packages.
Build and distribute software collections packages via centos.org as well as [http://www.softwarecollections.org SoftwareCollections.org]
Work with upstreams like OpenShift Origin and foreman to provide compatibility.
Resource Requirements
Full control of project space on [http://git.centos.org] - sig-sclo or similar.
Rights for SIG release engineering to SIG branch under the /rpms namespace on [http://git.centos.org] for builder access / control
Build privileges and related targets for [http://cbs.centos.org/koji]
Ability to sign packages for distribution (being done after requests like https://bugs.centos.org/view.php?id=9819)
Possible use of [http://bugs.centos.org] for tracking
Mailing lists and Communications
Work with the CentOS resources and any discussions around that will take place on the [http://lists.centos.org/mailman/listinfo/centos-devel centos-devel mailing list]. All work related to SCL, user interactions and upstream development will take place on the existing [https://www.redhat.com/mailman/listinfo/sclorg software collections mailing list].
The SIG is usually available also on irc at #centos-devel on irc.freenode.net.
Sync-up meeting
- at least in the beginning we hold (almost) weekly meeting on irc at #centos-devel on irc.freenode.net
- currently the meeting is held on Wednesday, 4pm UTC
- invitation to the irc meeting is sent to both mailing lists above usually one day before
SIG Membership
The SCLo SIG will have a steering committee and committers. The steering committee will initially consist of:
- Brian Gollaher
- Radek Vokal
- Joe Orton
- Adam Miller
- Thomas Oulevey
List of other members is available at https://accounts.centos.org/group/members/sig-sclo.
New committers and members may be added by the steering committee. Steering committee members may interface with the CentOS board via the bootstrapping board member.
Committer privileges, once earned, do not expire unless revoked by the steering committee.
Getting involved
- see [#communications mailing lists and other communication channels info]
- simple contribution doesn't require access to the dist-git and CentOS Build System (CBS)
have you some bug reports, patches to contribute, other things to discuss, use the [https://www.redhat.com/mailman/listinfo/sclorg sclorg@redhat.com] mailing list until there are some better ways (still working on this)
Some tips for active contributors
get familiar with the [https://www.softwarecollections.org/en/docs/guide/ Software Collections guidelines] and [https://fedoraproject.org/wiki/Packaging:Guidelines Fedora Packaging Guidelines]
- send introduction to the mailing list above (share some basic info about yourself, your intentions within SCLo SIG, which collection you plan to help with)
for gaining access to CentOS Build System, follow steps at http://wiki.centos.org/HowTos/CommunityBuildSystem
Roadmap and initial actions
- Define initial package set and deliver binaries.
- Establish git workflow
- Define criteria for contributions
- Provide documentation for community users as well as contributors
- Establish policy/practice for bug submissions
- Set release cadence and upgrade policies
Task list
The following are things that are on the todo list:
prepare release package for RHEL, so RHEL users can install SCLs from sclo namespace
- implement authtag to be able to work with dist-git to store SRPMs for SCLo packages
until it is ready, we plan to import packages manually as requested here: https://www.redhat.com/archives/sclorg/2015-September/msg00005.html
- after dist-git is ready, we want to be able to build SRPMs from SCM, which is not possible from sclo/ namespace, so we'll need some tooling around this, so importing into rpms/ namespace is not manual
tests for the packages live at https://github.com/sclorg/sclo-ci-tests, currently being integrated into CentOS CI
- CentOS packages were already introduced before, we need to solve update path for those (some have newer NVR than what we have in cbs now) -- ready for packages, not for centos-release-SCL to centos-release-scl package
- create a sub-page for docker images that are based on SCL
- softwarecollections.org to start using packages from cbs.c.o
This is a list of Software Collections from RHSCL 2.1 and their rebuild status inside SCLo SIG:
collection name |
status |
depends on |
comment |
devassist09 |
|
|
|
devtoolset-3 |
|
rh-java-common maven30 |
|
devtoolset-4 |
|
rh-java-common maven30 |
|
git19 |
|
|
|
httpd24 |
|
|
|
mariadb55 |
|
|
|
maven30 |
|
rh-java-common |
only deps for other SCLs, no need to announce |
mongodb24 |
|
v8314 rh-java-common maven30 |
|
mysql55 |
|
|
|
nginx14 |
|
|
nginx14 SCL was never considered GA quality, so there are no plans to release it |
nginx16 |
|
|
|
nodejs010 |
|
v8314 |
|
perl516 |
|
|
|
php54 |
|
httpd24 |
|
php55 |
|
httpd24 |
|
postgresql92 |
|
|
|
python27 |
|
|
|
python33 |
|
|
|
rh-java-common |
|
maven30 |
only deps for other SCLs, no need to announce |
rh-mariadb100 |
|
|
|
rh-mongodb26 |
|
v8314 rh-java-common maven30 |
|
rh-mysql56 |
|
|
|
rh-nginx18 |
|
|
|
rh-passenger40 |
|
ruby193 ror40 ruby200 rh-ror41 rh-ruby22 |
|
rh-perl520 |
|
|
|
rh-php56 |
|
httpd24 |
|
rh-postgresql94 |
|
|
|
rh-python34 |
|
|
|
rh-ror41 |
|
rh-ruby22 v8314 |
|
rh-ruby22 |
|
|
|
rh-varnish4 |
|
|
|
ror40 |
|
ruby200 v8314 |
|
ruby193 |
|
|
|
ruby200 |
|
|
|
thermostat1 |
|
rh-java-common maven30 rh-mongodb26 v8314 |
|
v8314 |
|
|
only deps for other SCLs, no need to announce |
This is a list of Software Collections that are not part of RHSCL:
collection name |
status |
depends on |
comment |
sclo-ror42 |
|
rh-ruby22 v8314 |
[http://wiki.centos.org/SpecialInterestGroup/SCLo/RubyOnRails Further info about SCLo RoR builds] |
sclo-vagrant1 |
|
rh-ror41 rh-ruby22 |
[http://wiki.centos.org/SpecialInterestGroup/SCLo/Vagrant Further info about Vagrant SCL] |
Requesting CBS tags
If you want to create tags and targets for a new collection follow these steps:
- Bring the idea of having new collection to the sync-up meeting (see above)
- Work together with the steering committee to choose appropriate name of the collection and namespace (rh or sclo)
follow the example to ask for the tags/targets: [https://bugs.centos.org/view.php?id=9661]
Building packages for SCLo
Currently there is still no dist-git repositories available for the SCLo packages, but we can build packages directly like this:
cbs add-pkg sclo7-rh-mariadb100-rh-candidate --owner=sclo rh-mariadb100-mariadb cbs build sclo7-rh-mariadb100-rh-el7 rh-mariadb100-mariadb-10.0.18-1.el7.src.rpm
Once build, we want to tag them to the -testing repos,
cbs add-pkg sclo7-rh-mariadb100-rh-testing --owner=sclo rh-mariadb100-mariadb cbs tag-build sclo7-rh-mariadb100-rh-testing rh-mariadb100-mariadb-10.0.18-1.el7
Then we may test them by installing the packages from CBS repository:
yum-config-manager --add-repo=http://cbs.centos.org/repos/sclo7-rh-mariadb100-rh-testing/x86_64/
When we want to release them, the process is the following:
- tag builds into -release tag:
cbs add-pkg sclo7-rh-mariadb100-rh-release --owner=sclo rh-mariadb100-mariadb cbs tag-build sclo7-rh-mariadb100-rh-release rh-mariadb100-mariadb-10.0.18-1.el7
sign and release packages into http://mirror.centos.org (ticket to be send like https://bugs.centos.org/view.php?id=9838)
announce release to https://lists.centos.org/pipermail/centos-announce/ (like https://lists.centos.org/pipermail/centos-announce/2015-December/021577.html)
- we need to announce separately for CentOS 6 and CentOS 7
- we must test properly that the steps mentioned in the announcement work
The collection naming breakdown
Software collection's name is cohesive identification that was chosen by author and is not supposed to be broke down to separate parts.
However, since the naming usually follows some guidelines, there is an example of sclo-vagrant1 software collection:
<sclo> : The goal of prefix in the SCL name is *not* to scope or brand the software collection, rather it is to "namespace" it. Prefix "rh-" is used in case of Red Hat's collections available in Red Hat Software Collections product; or "sclo-" in case of collections created by the community.
A prefix in the collection name: 1) allows "others" (users in particular) to have a distinguishing name per their requirement 2) SCL authors have one "collection name" wherever the collection will appear 3) users (open source projects, paying, whatever) have one collection name to target irrelevant of platform More on the prefix available at: https://www.redhat.com/archives/sclorg/2015-February/msg00022.html
<vagrant> : This is the app which is being shipped as the primary component. A collection will often include many support components. Eg on the php collections, many php extensions and pear modules are also shipped in the same collection, under the same collection name.
<1> : Denotes the major version and the level at which the abi will be tracked. Examples might include ruby197 ruby200 etc