06 March 2009

Nine pregnant gals in a queue

a pregnant lady
I wrote a bit ago on the fact that the CentOS 5.3 update release was proceeding apace. I may have been insufficiently direct.
If you feel you need the facilities provided by the CentOS project sooner than it is provided, or that you need deterministic releases of support: Please go buy such from our upstream, or from a third party vendor who can sell you the expedited subset of services truly needed.

Almost all of the CentOS team have active consulting practices, or had such before their present $DAYJOB. They had demonstrated the ability to handle the matter.

Similarly, CentOS' upstream has a unit cost for a three year JBOSS and their enterprise distribution product of US $297 -- WITH non-metered support -- This is unbeatable to point your pointy haired boss at when she is badgering you about 'CentOS is late'.

We are not late of course; we will issue the 5.3 respin when it is right, and not before. There was some loose talk speculating that there were insufficient resources, or that QA testing had not begun. Neither is correct.

Consider the well known lesson as to the futility of trying to parallelize a task at a sequential constraint chokepoint. This was pointed out by Fred Brooks in The Mythical Man Month.
Adding manpower to a late software project makes it later.

Brooks constrains his example to late tasks, but it turns out this is a broader rule than that, and has general applicability.

A quick example might be to consider the time it takes to produce one new human baby. For one woman, the time is nine months. No matter how hard they try, nine women working in parallel cannot get that one baby any quicker by adding eight more pregnant women to that queue.

CentOS has some goals in its build process which the upstream does not -- we strive to produce the packages we release on a 'self-hosting' basis, so that anyone who works at it can replicate our work freely. Upstream has never had that goal in their RHL nor now their Enterprise product. We have to identify failures with the tools such as the ones KB talked about recently.

Also, build sequence matters a lot in bootstrapping into a next point release; there are hidden build order dependencies which need to be solved -- sort of like packing a station wagon with furniture and household goods, when moving. The big stuff HAS to go in first, and the little stuff later placed in 'found' gaps. This cannot be well parallelized.

We have the QA team up and primed [there is a non-public webpage, and I see 29 members by a quick count]; the needed ACL's to get at the candidates are in place and tested [I pushed an update earlier this week for one member]; some QA has occurred. I updated some results I had announced a couple weeks ago, in a coordinating mailing list on the QA's notes on this release as well.

This is a little too wide a parallelizing fanout, in terms of coordination of testing, but it happens to be how it turned out this time. The future with a CentOS 4.8 and 6.0 coming will probably be a bit smaller. The QA master (and indeed I hope, each of the 29 individually) will review the participation at the end of this cycle, and some on the list will get dropped from a QA role, and slots freed up for new members to be invited in.

Experience has shown that there is no sense adding 'community' that does not put their shoulder to the wheel and work; We on the CentOS team see the laments from people wanting to join. It seems to me from watching, that they really want to consume and not carry the load of CentOS. Note that 'users' of CentOS are not our target 'community'; they are welcomed, but really, how does having lots of support HELP the project; the main IRC channel #centos is consciously limited to CentOS specific issues, and structured as a learning environment for a reason.

Want to be asked onto CentOS QA? Go for it, there are no barriers to demonstrating competence and interest in any of the following venue: file good bugs; comment bugs with reproducers or better, fixes; participate on a sustained basis in a knowledgeable fashion on any of: mailing list, wiki, forums, and IRC

The CentOS team watches all these venue all the time -- the CentOS 'community' is a meritocracy, and merit will be welcomed in -- but also know, this means there is an implicit 'Bozo filter' as well.clowns