-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 thus Karanbir Singh spake: > On 01/05/2011 01:19 PM, Timo Schoeler wrote: >> Furthermore -- again, I don't want to cause any bad blood here -- I >> *heard* from people involved or at least informed in the building >> process that there *are* 'special scripts' (involved in the build >> process) that are kept secret. > > erm, where did you hear about this ? Somewhere. > Red Hat dont publish their build > scripts for the distro - but we very much use the anaconda included > scripts for the isos. Is there anything else that you are referring to ? > for the buildsystem for rpms, c4/5 are built in a plague-server hosted > setup, its patched up in quite a few places but there is nothing > 'special' about it. Most of the patching is to handle the odd build > distribution process that we have to work with. Sure. But it's not open. So when someones wanting to help, he'd have to build the stuff himself, run into problems you (and surely others) ran into ages ago, re-invents the wheel a dozen times, gives up or does not give up and then, maybe in some bright future time, may become a contributor...? > The keysign and move to release process is not public, it never will be. Details. This stuff is details. > Buildsystem services are not public, they never will be. And just to be > clear, the 'never will be' is subject to situations, resources and > target goals. If you want to send over ~ 90k GBP to setup a homogeneous > buildservice - and then offer to pay for a person's full time salary > while they work with this system - let me know and we can work something > out. Let me know what's the difference between sending 90k GBP and setting up a community that's strong (and open :) enough to set up a homogeneius buildservice? I guess there's more than enough people here that would happily donate a build server in their location -- just have a look at the massive amount of mirrors available. Compared to running a mirror, I guess setting up a host that 'donates' CPU cycles/storage/RAM/network to a distributed buildservice would be a minor hassle. Well, I could and would provide at least one (modern) build host. That said, just as a hint: It'd be much easier for people doing so using an open documentation/howto... >> "yes, we have things we don't want to share due to this or that reason >> but you are welcome to join us in IRC or somewhere else to see how we >> can get you involved helping CentOS" would be a signal. YMMV. > > Can you point me at the place where you saw this ? That's the problem: Nowhere. >> Just have a look at other projects like FreeBSD, or even OpenBSD. Yes, I >> think one should use this as a reference. Not the bad or mediocre ones. > > why ? neither of them do anything like centos ? No. They do even more. They develop a whole OS, whereas CentOS has the luck of relying on a proven, enterprise-class basis that surely needs lots of hard work to become CentOS; nevertheless, everyone can build his own NetBSD isos just following the guide: http://www.netbsd.org/docs/guide/en/part-compile.html >> The CentOS wiki is a good starting point. But at the moment it's not in >> the best state, AFAICS. Yes, I know everybody can help here -- but why >> not attracting people by creating more openness? > > that's just very abstract and generic stuff. Can we please focus on > specifics. eg. you dont want to spend anytime looking at the wiki > because you cant see the script used to convert bash-foo.src.rpm into > bash-foo.i386.rpm ??? I never said that. I guess you get bogged down in details. It's about 'the whole process of building a CentOS release'. > I must be missing something here, otherwise that > sounds quite mad. Specially when that script is hosted in a binary ( > rpm-build ) included in the distro. I'm aware of that. >> What's the problem? Opening the code base (or build process, scripts, >> etc), so that anyone can 'try it at home' will not hurt the project. Not >> doing so, however, does hurt. > > Timo, i suggest you look around a bit. The mock ver we use, the scripts > everything are already included in the publicly available stuff. I can > only guess here that you havent actually made any effort to either look > or even understand what it is that CentOS does. Karanbir, I'm pretty sure that I have at least something like an idea what CentOS is. Please re-read my email -- it's about the work actually being done by the developers, it's not about the tools. Imagine ancient times: Man discovers fire. There's wood in many many places on earth (this is 'the tools'), but fire only in certain (rare) places (this is 'the work being done building CentOS'). Nobody's interested in wood here. That's just plain downloading the SRPMs. The fire is interesting -- what to do to get your CPU cycles burnt finally give birth to an ISO. :) >> Its simple maths: Open it, have 9,382 people try it, 43 fixing bugs, 23 >> reporting back to you. (However, I doubt that in case 43 people applied >> working patches only 23 would report back -- that really would be a >> waste of time and energy.) You win 23 developers. > > erm, I guess you need to go back and look at what CentOS is and what we > do. Because that process you just outlined would be a massive waste of > everyone's time. Yupp, I'll search the interwebz for that 'CentOS' thingie... *sigh >> By not opening the process the count of those 'usual suspects' will at >> best remain at the current level. > > I disagree. How do you think the usual suspects got to being the usual > suspects ? By the way they became the 'usual suspects', I guess. But the way may change or might have changed. I don't know. > - KB Timo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFNJH3Ufg746kcGBOwRAgX3AKCrzXndxg/P2W5YSHsG15ZdXPHybwCgrtL2 RvGpBvhZUjEeCuTlMhe4ceg= =wd60 -----END PGP SIGNATURE-----