FAQ
I'm curious about the status and goals of the RPM Packaging SIG but there
is no information available on the site. Since my company switched to
CentOS last year I have been building and maintaining RPMs and
YUM repositories for our projects. I'd like to continue building my skills
in this area and help out CentOS at the same time. If there's some way that
I can help in this area please direct me to any information on the subject.

Thanks,
Travis Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.centos.org/pipermail/centos-devel/attachments/20120718/da52356a/attachment.html

Search Discussions

  • Karanbir Singh at Jul 18, 2012 at 6:00 pm
    hi Travis,
    On 07/18/2012 03:10 PM, Travis Paul wrote:
    I'm curious about the status and goals of the RPM Packaging SIG but
    Status is : stagnant.

    Goals for the effort were to reach out and help other projects bring
    their code into a release format with rpm spec files that are of
    reasonable quality and release them into the CentOS-Contrib / Extras /
    Plus repos. The idea was to either 'adopt' something upstream, or to
    work with an upstream entity to make that happen.

    This is a direction opposite to the idea of packagers who then have no
    mechanism of feedback into the upstream code or the ability to take
    patches/ bugfix etc upstream.
    there is no information available on the site. Since my company switched
    to CentOS last year I have been building and maintaining RPMs and
    YUM repositories for our projects. I'd like to continue building my
    skills in this area and help out CentOS at the same time. If there's
    some way that I can help in this area please direct me to any
    information on the subject.
    The original goal was to focus on core infrastructure components -
    mostly since thats the stuff that I care about the most myself. eg.
    MariaDB / PgSQL / httpd / php / ruby etc - all places where we can
    target real functional areas that CentOS is used in by a large number of
    people. I also know there was quite a bit of interest in getting some of
    the cloud stacks into the CentOS repos - we could do with Eucalyptus,
    cloudstack, openstack etc being available directly. And the projects
    gain by being able to export the code at a much lower barrier to entry
    for the users.

    The actual mechanism to make this happen is all in place, in the weeks
    leading upto 6.3 we were working to stabilize the process and get the
    basic infra up around the process. That took a bit of a break while we
    worked through 6.3 but now that release is done, we can go back and
    finish that stuff up, get it public and start building rpms !

    I use the 'we' to indicate the QA team in this case, we've been working
    on the alt.bsys in the #centos-qa irc channel.

    Happy to answer any questions, and thanks for offering to help - there
    is plenty of scope to pitch in with.

    --
    Karanbir Singh
    +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
    ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax
    GnuPG Key : http://www.karan.org/publickey.asc
  • Travis Paul at Jul 19, 2012 at 10:47 am

    On Wed, Jul 18, 2012 at 6:00 PM, Karanbir Singh wrote:

    Goals for the effort were to reach out and help other projects bring
    their code into a release format with rpm spec files that are of
    reasonable quality and release them into the CentOS-Contrib / Extras /
    Plus repos. The idea was to either 'adopt' something upstream, or to
    work with an upstream entity to make that happen.
    So the aim is to have RPM specs maintained by the members of the
    upstream project? Such that the project maintainers can more readily
    apply patches/bugfixes? Just making sure I understand.
    I use the 'we' to indicate the QA team in this case, we've been working
    on the alt.bsys in the #centos-qa irc channel.
    Happy to answer any questions, and thanks for offering to help - there
    is plenty of scope to pitch in with.
    I will check out the #centos-qa irc channel, and also start building some
    of the core components that I rely on (php/httpd/MySQL) to get an
    idea of the state of their rpm specs. I have been taking for granted how
    much work and patches must be put into those specs.

    Thanks for the guidance,
    Travis Paul
  • Karanbir Singh at Aug 1, 2012 at 7:49 pm

    On 07/19/2012 03:47 PM, Travis Paul wrote:
    So the aim is to have RPM specs maintained by the members of the
    upstream project? Such that the project maintainers can more readily
    apply patches/bugfixes? Just making sure I understand.
    Maintained by them, or maintained in a way that they are involved. For
    the reason you mentioned. It also means that what we are doing isnt so
    far removed from the project upstream that there are support and feature
    issues in the chasm that opens up.
    I will check out the #centos-qa irc channel, and also start building some
    the #centos-qa channel is invite only, and presently limited to the
    actual centos-qa team, but there is no reason why the buildsys stuff
    cant move to the #centos-devel channel soon. The whole thing seems to
    work well enough.
    of the core components that I rely on (php/httpd/MySQL) to get an
    idea of the state of their rpm specs. I have been taking for granted how
    much work and patches must be put into those specs.
    Cool.

    btw, in terms of blockers - the biggest issue I have at the moment is
    getting a reasonable web wrapper around the git code. Been testing
    things at https://nazar.karan.org/ - but as you can tell, its not the
    most performance oriented stack.

    Also look at https://nazar.karan.org/sources/Workflow.txt and
    https://nazar.karan.org/sources/get_sources.sh ( as a basic model to
    start from )

    I've looked at gitorious, and thats way too much hassle and is super fiddly.

    I've also looked at gitlab and that has no public interface to the repos
    - also, it needs about 4 times more storage than gitblit needs and does
    not integrate too well with git://

    We could just consider something like cgit for a UI and use git:// with
    gitolite and ssh as transport for the code itself.... At the moment, it
    does seem tempting to go back to using something as simple and as basic
    as that.

    --
    Karanbir Singh
    +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
    ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax
    GnuPG Key : http://www.karan.org/publickey.asc

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos-devel @
categoriescentos
postedJul 18, '12 at 10:10a
activeAug 1, '12 at 7:49p
posts4
users2
websitecentos.org
irc#centos

2 users in discussion

Karanbir Singh: 2 posts Travis Paul: 2 posts

People

Translate

site design / logo © 2022 Grokbase