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