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
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.
On Wed, Jul 18, 2012 at 6:00 PM, Karanbir Singh mail-lists@karan.org 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
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 -
Travis Paul