On Thu, Feb 17, 2011 at 7:26 AM, Dag Wieers <dag at wieers.com> wrote: > On Thu, 17 Feb 2011, Karanbir Singh wrote: > >> On 02/16/2011 11:27 PM, Dag Wieers wrote: >> >>>> The C in cent means Community. >>> No, no, you have it all wrong ! The C in CentOS means Closed ;-) >> >> Thats not helpful, really. I know and thought we had previously >> established that the idea of this community is mostly alien to you. > > I thought we previously established that the CentOS developer(s) were not > interested in a transparent development process that would take advantage > of the resources of our community to speed up releases. It's not always that helpful, Dag. Sometimes too many cooks *can* spoil the broth. >> Have you ever considered the idea that the centos developer community ( >> as opposed to the centos community at large ) are all people who have >> @redhat.com email address's ? > > You seem to imply that there's only Red Hat and the CentOS community, if > that's the case, and we all share the same privileges, where can I > download the current state of the rebuild, the build-process, the current > state of the changes ? I'd also appreciate access to the build tree. Dag's work over at RPMforge is an excellent example of how such an open structure *can* work, and some of us could help detect the bugs earlier. > If this would be transparent, people would be able to help and improve the > process. At the moment the community is at mercy to any weaknesses in the > process for the security of their systems, held hostage by a handful of > (volunteer) developers. > > I, for one, do not think it is normal existing user's security is 2 or 3 > months at stake. Especially if there are people willing to help in this > regard and/or willing to roll their own if needed. Like me! For example, there are some changes in default structures for .spec files for RHEL 6. (The use of '^global' rather than '%define wherever feasible, and the use of '%BuildArch: noarch' for documentation packages.) I'd be happy to work with the components such as mock that are useful for both architectures and are critical parts of the "extras" utilities. EPEL has been doing this for RHEL 6 compatiblel components, and some modest tweaks would let the same .spec files work well for new and old versions of CentOS.