On 02/21/2011 08:33 AM, Dag Wieers wrote: > On Sun, 20 Feb 2011, Johnny Hughes wrote: > >> On 02/20/2011 07:30 PM, Dag Wieers wrote: >>> On Wed, 16 Feb 2011, Johnny Hughes wrote: >>> >>>> On 02/16/2011 04:31 AM, David Sommerseth wrote: >>>>> On 15/02/11 17:25, Gilbert Sebenste wrote: >>>>>> Let's see. 7 weeks after a RHEL release, we have: >>>>> >>>>> For RHEL6, lets make that 14 weeks. And RHEL5.6 got released 9 weeks after >>>>> RHEL6. >>>> >>>> The FIRST build of a distribution (the .0 of 4.0 or 5.0) takes MUCH >>>> longer than the subsequent rebuilds. This is because you have NOTHING >>>> to start from except SRPMS. You also do not know the environment that >>>> upstream is using to run their "Build Roots" in. We also know nothing >>>> about which packages will and will not build as written (there are many >>>> that require us to research and provide hints to the build suystem. >>>> Hints are things that need to be added that are not called out in the SRPM). >>> >>> CentOS 4.0 was released 23 days after RHEL4.0 >>> CentOS 5.0 was released 29 days after RHEL5.0 >>> CentOS 6.0 is *not* released 103 days after RHEL6.0 >>> >>> Source: wikipedia >>> >>> Granted, RHEL6 is larger than RHEL5 which was larger than RHEL4, still... >>> >>> PS And this time I am not off-by-1 (month) ;-) >> >> It is not done, I don't know when it will be done. All the jumping up >> and down and screaming is not going to get it done any sooner. > > I am not sure where you got that information, but I wasn't jumping up and > down and screaming ;-) > > >> On the initial pass through builder for C4, maybe 30 packages needed to >> be fixed because the links were bad. >> >> On the initial pass through builder for c5, maybe 20 packages needed to >> be fixed. >> >> On the initial pass through builder for c6, there are hundreds of >> packages that need to be analyzed. > > So you are now saying that you cannot scale out this work to more people > to release faster ? This is something that has to be done by Karanbir only ? > Dag, The packages have to be built in a specific order, preferably the order that they are originally produced in, so that they can be linked properly. Package A builds, then Package B, then Package C. If package B is broken, it needs to be fixed, then Package C needs to be built, etc. This is not something that can be done by several people at the same time in parallel, no. Not and be done correctly. This is very complex to bootstrap an OS from the beginning when upstream does not provide all the build requirements in one repo. I am not sure what you want ... mabye you should try building it yourself and see how easy or hard it is. Seeing as how we are currently dealing with 2 trees in the QA directory for testing right now (4.9 and 5.6) ... 6.0 will be waiting until we get those out of QA. -------------- 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/attachments/20110221/99df33e7/attachment-0005.sig>