The PHP-team is not following Gentoo Developer Handbook. PHP5* has gone from ~x86 to hardmask. The 5.0.x-builds do not work. (5.0.4, 5.0.4-r1, 5.1.0_beta). Missing binaries and so on. I know running ~x86-builds in an production environment is to ask for trouble, but this is ridiculous. PHP5 is stable and should be at least as ~x86 in portage. Now, suddenly the entire PHP5-tree has gone hardmasked. I don't know how many gentoo-installations that's broken now, but my guess is quite many. _this hurts end users, and ultimately, Gentoo_ Reproducible: Always Steps to Reproduce: 1. emerge dev-php/mod_php-5.x.x 2. wait a few days 3. emerge sync && emerge -uD world 4. enjoy your new php4 and broken webapps. Actual Results: Broken webapps. Expected Results: Functioning webapps. The PHP-team need a mature team leader with focus on _reliable relases_ and _end user stability_. Gentoo needs user trust. If noone steps forward, I can fill that role. Just contact me. At least, the PHP team should follow Gentoo's guidelines on relases.
A mistake was made with php5, it happens. If it happened in stable I might consider this something other than a whine. If you're running ~x86 in production, I'm gonna have to say tfb -- take it up with the php team. (They tell me it's masked until all the php extensions & deps in the tree are ready) There's nothing stopping you from unmasking it (/etc/portage/package.unmask) if you really know what you're doing and want to use it. (As a sidenote, implied insults against the PHP team leader and expressing a desire to take his place don't help your cause a whole lot...) Closing, mild hiccups in ~x86 just aren't a devrel issue.
First off; sorry if I sounded whiny. That was not the point at all. What really troubles me is: 1. PHP-5 is stable. The ebuild for mod_php-5.0.3 was well functioning and was in ~x86. All reports I've seen tells me it was ready for release. 2. mod_php-5.0.4 broke the install. This resultet in hardmasking of _all_ php5-related packages in portage. IMHO the correct cycle would be; 1. Verify 5.0.3 as ready for release, and relase it. 2. Introduce 5.0.4 as ~x86 and find out it's broken. 3. hardmask >=dev-php/mod_php-5.0.4 PHP-5.0.0 was relased 2004-06-31, close to a year ago. One would think some stable version of it were in portage. I don't know where to direct my concerns, but here. If you have a better suggestion, please let me know.
My understanding is that it's not masked because there's anything wrong with it per se; it's masked because the tree's not ready for it. Feel free to contact stuart@gentoo.org for more information.
<peace> I knew this was bound to happen. Everyone makes mistakes - but making the same mistake for three consecutive times obviously calls for a better QA. I hope the point is made. As I
<peace> I knew this was bound to happen. Everyone makes mistakes - but making the same mistake for three consecutive times obviously calls for a better QA. I hope the point is made. As I´ve already noted in Bug 95777, users can do a lot of testing and debugging for Gentoo - but they expect some consistency and predictability; and removal of all ~arch ebuilds and putting of the whole thing into package.mask certainly won´t make them happy. It would also be helpful if PHP herd did not leave a bug unanswered for 5 days (like Bug 95931). *sigh* </peace>
Hang on a moment! This is a community distro, built by volunteers who donate their free time to work on this project, and you're complaining that a bug has gone unanswered for five days? If you want *that* level of support, feel free to contact me via email or IRC and I'll happily discuss the terms of a paid-for support contract with you. You may want to consider running something like RedHat or Fedora, which is backed by a full-time workforce. We have reliable releases. The reliable releases of the PHP packages can be found in the stable tree. If it's not in the stable tree, please don't rely on the package. The ~arch tree is for testing packages which work. The PHP packages don't work suffiently yet, and so (correctly, imho) have been withdrawn from ~arch until they do. I can't agree with you on what the 'correct' cycle should have been. Whoever has been telling you that those packages are close to being ready to go into the stable tree has misled you, I'm afraid. * PHP 5 has a large number of USE flags. We need to ensure we've tested them adequately. * PHP 5 isn't backwards-compatible. The tree needs to be tested to ensure that all webapps depend on the PHP4/5 correctly. * PHP 5 isn't backwards-compatible. We need to be able to support a mixed php4/php5 box. The PHP5 side of this is partly done, but the changes to PHP4 haven't been started yet. (This one will be even more important if PHP6 appears later this year) * The PHP packages aren't standalone. We need to roll out a solution for the PECL ebuilds; to date, there's been no agreement on how best to do this. * At least one arch team has can't consider keywording PHP5 until we can provide test cases for PHP. That's a large job too, one we haven't started on yet (I'm hoping to talk them round) * We have no documentation yet on how to run a mixed PHP4/PHP5 system. The Gentoo documentation team have been approached, but were unable to help at the time. Bugs like this aren't really the best way to resolve non-personal complaints like yours. I'm around during UK office hours in #gentoo-dev, #gentoo-apache and #gentoo-web on our IRC channels. I can be reached via stuart@gentoo.org (although I can't read that from here @ work). Come and talk to us, please. Best regards, Stu
(In reply to comment #5) > Hang on a moment! This is a community distro, built by volunteers who donate > their free time to work on this project, and you're complaining that a bug has > gone unanswered for five days? I did not file _this_ bug, I did not even file the other bugs for whatever that matters. Anyway - I wrote unanswered - NOT unsolved. Just wanted to say that it would be really helpful to drop a two lines there - like sorry, we are working on it or whatever explanation (like you did in this bug). It is really hard to understand why exactly the same mistakes happened three times in a few days. > If you want *that* level of support, feel free to contact me via email or IRC > and I'll happily discuss the terms of a paid-for support contract with you. I don
(In reply to comment #5) > Hang on a moment! This is a community distro, built by volunteers who donate > their free time to work on this project, and you're complaining that a bug has > gone unanswered for five days? I did not file _this_ bug, I did not even file the other bugs for whatever that matters. Anyway - I wrote unanswered - NOT unsolved. Just wanted to say that it would be really helpful to drop a two lines there - like sorry, we are working on it or whatever explanation (like you did in this bug). It is really hard to understand why exactly the same mistakes happened three times in a few days. > If you want *that* level of support, feel free to contact me via email or IRC > and I'll happily discuss the terms of a paid-for support contract with you. I don´t need a support contract and I don´t think that the guy who filed this bug needs such a contract either. It´s just disappointing to see things break the same way all over again and b0rked ebuilds getting into portage while the working ones being removed. > The PHP packages don't work suffiently yet, and so (correctly, imho) have been > withdrawn from ~arch until they do. Uhm, they certainly worked better before all these moves have been done. Things are considerably more broken now than they used to be with 5.0.3. > * PHP 5 has a large number of USE flags. We need to ensure we've tested them > adequately. Sorry, no-one can test it and help you if PHP5 is missing php and pear binaries. IMHO, unuseable packages don´t belong to the tree at all, not even to package.mask. > * We have no documentation yet on how to run a mixed PHP4/PHP5 system. The > Gentoo documentation team have been approached, but were unable to help at the > time. Quite a few guys offered help in the related bugs - yet the response looks like that you don´t need any; so I can´t see the point of your complaint. You rarely get help if you don´t ask for any, so much the more when you seem to refuse people willing to help. > Bugs like this aren't really the best way to resolve non-personal complaints > like yours. Agreed. To finish this - there are (have been) a lot of people testing PHP5 who can´t really do that any more if state of things continues to be like now. I mean - repeatedly releasing a PHP package which is missing php is really, *ahem*, unfortunate at least. Such minimal QA really has to be done by Gentoo devs themselves, not by users. And users _will_ complain if this happens three time in one week, take it for granted, hard-masked or not. Oh, and thanks for your explanation in comment #5, at least the situation is more clear now.
Jakub, > I did not file _this_ bug, I did not even file the other bugs for whatever > that matters. Anyway - I wrote unanswered - NOT unsolved. Just wanted to > say that it would be really helpful to drop a two lines there - like sorry, > we are working on it or whatever explanation (like you did in this bug). It > is really hard to understand why exactly the same mistakes happened three > times in a few days. We look at, and respond to, bugs as and when we have time. If there's no response, it's because we haven't had time to read the bug. > I don
Jakub, > I did not file _this_ bug, I did not even file the other bugs for whatever > that matters. Anyway - I wrote unanswered - NOT unsolved. Just wanted to > say that it would be really helpful to drop a two lines there - like sorry, > we are working on it or whatever explanation (like you did in this bug). It > is really hard to understand why exactly the same mistakes happened three > times in a few days. We look at, and respond to, bugs as and when we have time. If there's no response, it's because we haven't had time to read the bug. > I don´t need a support contract and I don´t think that the guy who filed > this bug needs such a contract either. It´s just disappointing to see > things break the same way all over again and b0rked ebuilds getting into > portage while the working ones being removed. Sorry, but I think you're either trolling or deliberately trying to make trouble here. You've switched your argument from a lack of response to complaining about broken packages. The PHP5 packages are masked precisely *because* they're broken. That's the whole point of the masking support in Portage. It's great if people have had success with the packages before now, but (as explained above) there are a number of problems which need to be resolved before these packages will be unmasked. > Uhm, they certainly worked better before all these moves have been done. > Things are considerably more broken now than they used to be with 5.0.3. That remains to be determined. The packages work as expected in my test environment, and I've had it confirmed that they also work for a number of our users. We'll get to the bottom of the problem, and determine what the cause is. > Sorry, no-one can test it and help you if PHP5 is missing php and pear > binaries. IMHO, unuseable packages don´t belong to the tree at all, not > even to package.mask. PHP5 isn't missing /usr/bin/php. PEAR is missing, but dev-php/php isn't responsible for installing /usr/bin/pear. That's what the masked PEAR-PEAR- 1.3.5-r1 is there for. > Quite a few guys offered help in the related bugs - yet the response looks > like that you don´t need any; so I can´t see the point of your complaint. Sorry, there's been a misunderstanding. I'm not complaining. > You rarely get help if you don´t ask for any, so much the more when you > seem to refuse people willing to help. I'm sorry if people have taken my comments that way. They certainly were never intended to come across like that. And, until now, no-one has approach me to discuss them at all. Mmm ... experience has taught that the people who need to be asked to help out unfortunately don't last. Those who are motivated enough to still be around 6 months or longer are the ones who make an sustained effort on their own, either by consistently posting patches and/or by coming and talking to the Gentoo developers. We get a lot of offers for help which come to naught; if we tried to chase every one of them, we'd never get anything done. People who genuinely are going to help need to make a real effort; then we'll match that and help them in return. > To finish this - there are (have been) a lot of people testing PHP5 who can´t > really do that any more if state of things continues to be like now. > I mean - repeatedly releasing a PHP package which is missing php is really, > *ahem*, unfortunate at least. I'd prefer to wait until the cause of the reported problem is uncovered before making statements like this. The package works in my local test environment, and has been confirmed to work by other users too. We need to eliminate user error first. > Such minimal QA really has to be done by Gentoo devs themselves, not by > users. And users _will_ complain if this happens three time in one week, > take it for granted, hard-masked or not. That is an inflammatory statement ;-) a) The package is *masked*. If you expect masked packages to work, and/or to be fit for use on production servers, then your expectations won't be met by Gentoo. We gratefully welcome bug reports about problems with all packages (masked or not), but outright complaints about masked packages not working *will* end up in /dev/null. b) There hasn't *been* three releases of dev-php/php-5.0.4, so I'm not sure where you get this figure from. c) The package has passed a certain level of testing in my test environment. My test environment is made from two separate copies of Gentoo; one which is a virgin install (stage 3 installed, portage upgraded, that's it), the other which was first installed back in the Gentoo 1.2 days and has been upgraded ever since. Please, by all means, help us get through the required work so that we can get a stable set of PHP5 packages into Portage. A good start would be for you to indicate which current bugs you can reproduce on your own system. Best regards, Stu
(In reply to comment #7) > ... Bugzilla is really not an appropriate place for such long discussions, so I will try to explain all the rest via email when I have time tonight. > Please, by all means, help us get through the required work so that we can get > a stable set of PHP5 packages into Portage. A good start would be for you to > indicate which current bugs you can reproduce on your own system. Lets move to some positive things: is there (I could not find any) or could you please file a tracker bug(s) for php5/mod_php5 so that it
(In reply to comment #7) > ... Bugzilla is really not an appropriate place for such long discussions, so I will try to explain all the rest via email when I have time tonight. > Please, by all means, help us get through the required work so that we can get > a stable set of PHP5 packages into Portage. A good start would be for you to > indicate which current bugs you can reproduce on your own system. Lets move to some positive things: is there (I could not find any) or could you please file a tracker bug(s) for php5/mod_php5 so that it´s easier to test things that need to be fixed before this goes at least back to ~arch? Thanks for you response.
Hi, Let's use bug 60438. I'll bring it up to date. Best regards, Stu
