On 02/19/2011 01:31 AM, . wrote: > On 2/18/2011 8:28 AM, Dag Wieers wrote: >> Everything is available from: >> >> http://svn.rpmforge.net/svn/ >> >> we have a viewvc front-end and a mailinglist to keep track of changes >> here: >> >> http://svn.rpmforge.net/viewvc/ >> http://lists.rpmforge.net/mailman/listinfo/svn-commits >> >> And there are mailinglists to suggest changes or discuss packages. But at >> least everything is shared. > I would like to say that in my opinion the system mentioned above > sounds better than what there is now, for outsiders. > > Now, I don't want outsiders to have access to the GPG keys, nor the > ability to push out new versions, but being able to see the source tree > as it is, and being able to download a mock config + setup instructions > would go a long way (again in my opinion). > > Forgive my naivete, but what is preventing us from doing such a > thing? Is this a lack of manpower/resources to set it up, or is this > more political as in; we don't want other rhel based distros to steal > our juju? > We release our SRPMS, that is our juju. Every patch is there for the looking. I have tried to explain, over and over again. You guys are trying to make the process different than it is. For most projects where RPMS are produced, you are getting an upstream tar ball that may or may not have a spec file ... you are creating spec file, you are creating lots of patches to change where WWW pages go or what directory things get installed in, etc. That is not the case with CentOS ... all of those changes are already in the "SRPM Source Tree". Our #1 goal (by far) is to be able to use that SRPM package exactly as it is ... to clone it and make our rendering of it as identical as possible to the original. For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem. For example, here is a problem that I had to solve for 4.9 yesterday. There is a hidden build requirement that the package gnome-volume-manager requires perl-XML-Parser to be in the mock build root for the package to build properly. This is NOT called out in the SRPM. We need to add it to the tree to build this package ... BUT, we do not modify the SRPM to make this happen, we instead modify the build root, and submit a BUG upstream for them to potentially fix this package. Since our goal is NOT to change upstream packages at all, this would not show up in this "SVN" or "GIT" tree of all the packages ... since we do not change (or want to change) the package that upstream has produced. In any other project besides CentOS, the fix would take 1 minute, it would be to add a "Build Requires: perl-XML-Parser" to the spec file in the SVN repo and regenerate the SRPM package. So, this time consuming tree that you want guys want us to create is not worth a hill of beans and adds nothing for the vast majority of packages, since the SRPM is unmodified from upstream. You have everything you need already in the SRPM. > For those about to say, help out or don't; I have helped out. I did > a handful of patches last month after reverse engineering the process > (http://thread.gmane.org/gmane.linux.centos.devel/6903/). Fast forward a > month, and none of the bug ids where I posted patches on have had so > much as their status changed. Before you jump down my throat on that, I > realize the priority was/is Centos 5.6 etc... > > I do believe that if we had a system similar to what Dag is using; > someone in the Centos community would have tried the patches I made, > maybe they didn't work and I needed to fix something or maybe they fix > it and upload a better version. I think progress would have been made > that wouldn't have detracted from the centos-devel's focus. > What makes you think that we HAVE a "split" source tree? CentOS builds someone else's SRPMS ... that IS our source tree, the SRPMS that are produced upstream. We only change a handful of SRPMS (the ones that are labeled .centos). We are not creating these packages, and in fact it is desirable that they do not change at all. We would be creating extra work to break down the SRPMS into their component parts and create this so called source tree. What would be the benefit of all this extra work since we do not change the vast majority of the packages. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20110219/179746e7/attachment-0007.sig>