Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   CentOS Development (http://www.linux-archive.org/centos-development/)
-   -   RPM Packaging SIG (http://www.linux-archive.org/centos-development/684852-rpm-packaging-sig.html)

Travis Paul 07-18-2012 02:10 PM

RPM Packaging SIG
 
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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Karanbir Singh 07-18-2012 10:00 PM

RPM Packaging SIG
 
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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Travis Paul 07-19-2012 02:47 PM

RPM Packaging SIG
 
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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Karanbir Singh 08-01-2012 11:49 PM

RPM Packaging SIG
 
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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel


All times are GMT. The time now is 11:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.