On Fri, Jul 4, 2014 at 6:49 PM, Johnny Hughes <johnny at centos.org> wrote: > On 07/04/2014 04:41 PM, Karanbir Singh wrote: >> On 07/04/2014 09:19 PM, Nico Kadel-Garcia wrote: >>> I'm sure it's easier to track and trace git.centos.org if you wrote >>> the system and evolved your tools to cope with it. >> you would do well to research the issue a bit, >> >> - KB > > So, the tools we used were developed after the git repo was populated. > Pat Riehecky, Tyler Parsons and Bonnie King from Scientific Linux > provided the patches for the existing tools to make them work much > better (and some of the tools themselves) ... and Brian Stinson from > Kansas State University provided centpkg. Kay Williams provided a tool > to help with branding identification. Testers put in bugs at > bugs.centos.org in a totally open QA process. Right. And you had direct access to the authors, and they had direct access to the build process. Come in from outside, and it looks like spaghetti until you spend a *lot* of time analyzing the code, which is changing even as we speak (witness centpkg). This is *normal*. A new build process almost invariably looks like spaghetti until some procedures and API's are written, and available, to provide defined procedures. There are little missing steps like "set up a working mock to build RPM's in" that someone from outside, with less experience than you or me, would not be aware of. > All of the mock configs are provided in git.centos.org: > > https://git.centos.org/tree/sig-core!bld-seven.git Wow! What an intuitive, apparent, and well labeled name, completely obvious from the git.centos.org front page! And its name makes it completely apparent that it contains the mock configurations, especially since it has no description whatsoever for the repo itself! I'm afraid you just made my point. It looks like spaghetti. And there is no link to 'bugs.centos.org' from the 'git.centos.org' website, which would be helpful. > the repos we built against are provided on buildlogs.centos.org > (starting with c7-*): > > http://buildlogs.centos.org/ > > We simply use the git repo to create an SRPM, then send it to mock to > build, the output you see there. And that's all cool, thank you for the pointers. Any chance of getting those into README.md for https://git.centos.org/tree/sig-core!bld-seven.git > I guarantee you, I am the one building the RPMs, and I am building them > using get_sources.sh, into_srpm.sh, return_disttag.sh, > show_possible_srpms.sh, etc. from centos-git-common: > > https://git.centos.org/tree/centos-git-common.git > > I use the activity log of git: > > https://git.centos.org/project/?p=rpms I've mentioned separately about that, *ouch*. I really think that you, as a builder, would benefit from consistent use of 'git tag' for denoting the avaious builds. > and the rhn public errata page > > https://access.redhat.com/security/updates/active/ > > to figure out if I need to build a package. > > The git tree is just an exploded SRPM ... rpmbuild -bp turns it back > into an SRPM, rpmbuild -bb (or mock) turns it into binaries. And boy, do I understand and sympathize with that process. I'd love to see the relevant mock configurations get into a relevant RPM with daily build compatible config files, but that would be dependent on the installation of a 'mock' RPM. That gets into weirdness with CentOS build environments being dependent on mock from a third party (such as the EPEL beta 7 repository), and needing something like a 'yum-conf-epel' RPM to enable EPEL, then something like a "mock-conf-centos-daily' package to enable CentOS nightly build access. Would that be acceptable? Would you like any of those, to help with offsite developers? I'd be happy to submit code! > There are no special tools, it is just repetitive, tedious work to check > the activity log, if something changes, then check it out from the git > repo, turn it into an SRPM, submit it to mock, sign it and put it where > it goes. That signature is, IMHO, too late. I'd love to see the signatures on git tags from the git repository itself, to help ensure provenance. But since you're the one doing signatures, I'm also afraid that would probably double *your* workload. > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel >