On 09/23/2011 12:29 PM, Dennis Jacobfeuerborn wrote: > On 09/23/2011 06:57 PM, Johnny Hughes wrote: >> On 09/23/2011 09:06 AM, Stefan Held wrote: >>> Am Donnerstag, den 22.09.2011, 07:28 -0500 schrieb Johnny Hughes: >>> >>>> No matter what we try to do ... some kind of rolling updates for people >>>> who do not want to wait ... or whatever the next thing is ... well you >>>> do not seem to be happy. >>> >>> Your "Customers" are not unhappy because they don't like what you do. >>> Your "Customers" are unhappy because they don't know what you do. >>> >>> The Release and QA Process seems recently to have become a mirracle. >>> There is nothing discussed where your Problems are in getting things >>> done. >>> >>> So if nobody knows where you are stuck. (Who are the persons anyway >>> hidden in the secret labs?!) Nobody can step up and help out. >>> >>> Where is this discussion maintained anyway? The Currents process is >>> untransparent. And for a "C"OMMUNITY "E"nterperise "O"perating "S"ystem >>> this fact is not acceptable. >>> >>> We know that the big boys at RH changed the whole system, but the >>> community accepted that you need time for 6.0 to adept to these changes. >>> >>> Since then we all thought the issues would have been solved. So what >>> now? What exactly is holding of the release of 6.1 and where can we as a >>> community step in and help? >>> >>>> If you aren't happy, well then we would recommend "something else" that >>>> does make you happy. >>> >>> Or give us the possibility to help becoming happy again. But doing it >>> like Dumbledore in secret regions of the Centos-Hogwards Terrertory is >>> an bad option as it seems. >>> >>>> Happy is important ... don't go through life unhappy because of an OS. >>> >>> You seem very unhappy at the moment ;) >>> >>>> We just want you to be happy Les. >>> >>> see my above text. >>> >> >> Are we going to start this again ... we are doing the best we can and we >> are building things as we go along to take care of issue when we hit a snag. >> >> There is a whole channel of RPMs that we are not allowed to look at from >> upstream now. They do not release them on any ISOs and we can't pull >> things directly off RHN (the only way to get the optional channel) and >> use it. This is just one of many issues we are having right now. >> >> If you can do it better, then do it. >> >> If you can not do it better, great, neither can we ... if we could have >> been done by now, we would have been by now. >> >> You can, as always, pay Red Hat for RHEL if you have servers where >> CentOS does not meet your update requirements. > > What you are suggesting here is that people should expect centos systems to > be insecure and go the RHEL if they want secure systems. > Have you pondered the moral implications of your statement? Does that mean > that the centos project is perfectly fine with knowingly distributing a > system that insecure and a danger not only to its users but to others as well? > Absolutely ... BINGO ... NOW YOU GET IT. If you want "point releases" on the day they are released by Red Hat, then you need RHEL ... CUT AND DRY. We will release things as fast as we can. If it is not fast enough for you personally, then yes, you need something else. > If as you also seem to suggest the project is so severly understaffed have > the people in charge considered shutting down the project? This might be > the more responsible option compared to having a lot of unsecured systems > out there for long periods of time. > > Another issue are the priorities of the project. So apparently you are busy > working on 6.0/cr and 6.x which is fine. But there is a major but in the > current apache packages with a known and released fix upstream. Why can > nobody make a manual build sign it and upload it to vault.centos.org? I told you why .. what else, besides apache needs to be updated? Can you tell me everything that httpd links against and everything that links against it? I'll give you a head start start, In order to build, I need these to be updated before I build httpd: autoconf perl pkgconfig findutils zlib-devel libselinux-devel apr-devel >= 1.2.0 apr-util-devel >= 1.2.0 pcre-devel >= 5.0 openssl-devel Now, I also need to upgrade anything that provides those packages before I build them ... for example, lets just take openssl: mktemp krb5-devel perl sed zlib-devel /usr/bin/cmp /usr/bin/rename So, if each of those need to be verified, and if each of the pre-reqts have 5 or 10 packages, now I need to rebuild up to 20 or so packages. So, once I build all of the pre-reqts, if required, then I can build httpd. Then we need to verify everything that uses httpd is updated or works OK with the this version. Can you tell me how using the 6.0 version of php or the mod_* stuff might react in this scenario? Where we have built a new httpd with the 6.1 gcc and glibc and against the new 6.1 libraries, but now want to install it in the 6.0 tree? Can you tell me how custom modules built by other users might react with this mix and match approach? All the packages are built in a specific order, what they build against, and what is available in the tree is important. > The fact that apparently people are busy with other stuff but this > important update is not considered worthy of anyone's attention is not a > problem that can be solved by adding more people but only by the current > people making better decisions. Drop whatever 6.x related things you are > doing, build the package, put it online, make an announcement and then get > back to the regular schedule. It is not just build 1 package and push it. If there are issues that prevent this then > make an announcement to that effect so that people at least know that they > have to take matter in their own hands. Writing such an email would take 5 > minutes and there are not technical hurdles preventing you from doing so. > This alone would already be a big improvement over the current situation. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20110923/e7275c84/attachment-0005.sig>