-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 thus Karanbir Singh spake: > Hi, Hi, I really didn't want to jump into this discussion, but... > On 01/05/2011 11:56 AM, Thomas Bendler wrote: >> the process could be more open, see SL i.e., but regardless how open the > > Couple of things worth clearing up: > > CentOS is not SL > CentOS and SL target a very different Goal Set ( there is user end > overlap, which imho is good ) > >> process is, due to the fact that no alpha, beta whatever relaeases are >> in the wild it is not possible to test the current state, check for > > When we asked around for help from people, the *currnet* state of CentOS > was a bunch of srpms that needed to be looked at for content audits. > These srpms are widely available. What do you want to do with these > sources that would imply to you a beta or an alpha state ? as far as I > am concerned those sources represent the final product pretty much. I think the OP didn't have the general availability of SRPMs in mind, but rather an open development/building process. To see where the problems and bugs are hidden, and not to re-invent the wheel a thousand times (or, each time a new individual tries to build stuff). In comparison to other distributions and especially the BSDs (which almost 'define' 'openness' IMHO) CentOS' development process is a black box to the majority of the community, regardless of the use of $searchengine or subscriptions to mailing lists. 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. IMHO the problem is not the existence of such scripts (if they exist), but rather the secret even about their (non) existence. A statement like "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. >> > Are there any plans to tackle the human bottleneck issues within the >> > CentOS development process? >> Absolutely, but tackle them by doing the right thing - and finding >> people who both (a) know what they are doing, (b) understand the CentOS >> process and (c) are able to bring a certain trust level to the community >> of users. >> Why not an open approach. > > Can you quantify what you mean by 'open approach' ( basically, what > steps and what gains those steps would bring about ) 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. 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? >> The aim was to focus people's attention to the upstream beta, better >> product and that loop etc. We could have started earlier, sure. But now >> that we have started 2 months back and your own contribution status >> stays at nil, why are you interested ? >> How and what should be contributed if the normal user didn't even know >> what problems remains? > > Problems remain where ? in CentOS or RHEL ? It was RHEL6 that had a > public beta, for issues that should have been reported against > bugzilla.r.c; or am I misunderstanding what you said ? As this is a CentOS list, I'm pretty sure that it's about CentOS and especially about the build process (of CentOS 6). > Don't get me wrong, I am well aware of the fact that there are issues > and situations that need looking at and changing. But lets do the right > thing rather than just doing something. Going by the popularist current > mood of people on this list, I think people just want early access to a > codebase they can start using for their own use rather than actually > working towards building CentOS-6. 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. 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. Do not open it, nobody reports back; maybe even worse, people interested in the project get annoyed and more inactive than they wanted to. > Which makes me fear that the only way > we are going to get C6 out of the door in the next few weeks is by > clamping up, talking to the usual-suspects By not opening the process the count of those 'usual suspects' will at best remain at the current level. > and just going back to the > CentOS-5 process. And to be honest, I don't really think these > conversations over the past two months have been wasted; but in the > grant scheme of things - getting 6.0 out of the door might be a better > target for now - as long as we can somehow agree that we get back to > this process engineering immediately after so as to not be in the same > situation, come 6.1. > > Also, failback to the CentOS-5 process isn't necessarily a bad thing - > we know it works :) > > - KB No pun intended, Timo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFNJG/Ffg746kcGBOwRAgx/AKCzFYtOmZQLkC8saPUomdO8X8ICnQCfUDbq Qip7n8X/QvCsJpUgWYhcTe8= =huxS -----END PGP SIGNATURE-----