Mailing List Archive

> As a PHP developer I believe that 5.0.4 is more then stable, and should
> be added and marked stable.
>
> I don't wanna override the system and install it manualy.
>

Then don't override the system, use it! You need to read "man portage"
sometime.

-Steve

--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 22, 2005, at 08:56, Stephen P. Becker wrote:

>> As a PHP developer I believe that 5.0.4 is more then stable, and
>> should
>> be added and marked stable.
>>
>> I don't wanna override the system and install it manualy.
>>
>
> Then don't override the system, use it! You need to read "man portage"
> sometime.

I think the point he was hitting is that the version PHP declares
'stable' is not even in our tree. This does strike me as strange.

Do we have any real hard evidence of anything that does indeed break
with the new version of PHP5? I've personally not delved much into it,
but I found it to run at least _my_ OO code just fine.

- --

Hasan Khalil
Gentoo for Mac OS X
Porting Co-Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFCaQ0DzsotBnB7jxgRAhUxAKCKtxxYX/Kl6Xh7hcTPWbs7VvtK2QCfTUqd
wge7TNj8Ww6CM6swckkyHJg=
=/JOG
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

maillog: 22/04/2005-10:41:07(-0400): Hasan Khalil types
> Do we have any real hard evidence of anything that does indeed break
> with the new version of PHP5? I've personally not delved much into it,
> but I found it to run at least _my_ OO code just fine.

xoops was not working with php5 a few months back.

--
| Georgi Georgiev | You never go anywhere without your soul. |
| chutz@gg3.net | |
| +81(90)2877-8845 | |

I've been working with it since it came out.

And I made big projects with more then a few classes and objects and it all
worked fine, I didn't have any problems with it.
It's not like a group of 100 people from microsoft tested it and said it's
ok, the entire community of PHP developers agreed it's alright and aprooved
it.
we're talking about one of the biggest OC communities.

I believe it's stable enough to get marked as stable on the portage tree.

Regarding the remark of not overriding the system, what I ment is that I
there's no reason to manualy unmask a stable product..

On 4/22/05, Georgi Georgiev <chutz@gg3.net> wrote:
>
> maillog: 22/04/2005-10:41:07(-0400): Hasan Khalil types
> > Do we have any real hard evidence of anything that does indeed break
> > with the new version of PHP5? I've personally not delved much into it,
> > but I found it to run at least _my_ OO code just fine.
>
> xoops was not working with php5 a few months back.
>
> --
> | Georgi Georgiev | You never go anywhere without your soul. |
> | chutz@gg3.net | |
> | +81(90)2877-8845 | |
>
>
>


--
Thanks,
Omer Cohen
www.omerc.net <http://www.omerc.net>
omerc.net@gmail.com

Omer Cohen wrote:
> we're talking about one of the biggest OC communities.

<flame>
...and the same community whose members write code like that described
in PHP's bug 31261 [1], which seems quite ugly, at least to me.
</flame>

My point is that even if developers say their code is stable, it doesn't
have to mean it *really* is, altough they're probably correct.

[1] http://bugs.php.net/bug.php?id=31261

--
cd /local/pub && more beer > /dev/mouth

Jan Kundrát wrote:

>Omer Cohen wrote:
>
>
>>we're talking about one of the biggest OC communities.
>>
>>
>
><flame>
>...and the same community whose members write code like that described
>in PHP's bug 31261 [1], which seems quite ugly, at least to me.
></flame>
>
>My point is that even if developers say their code is stable, it doesn't
>have to mean it *really* is, altough they're probably correct.
>
>[1] http://bugs.php.net/bug.php?id=31261
>
>
>
<water>
Sometimes happen to write lines of code not well written, not clear and
still working.
Simply that, sometimes happen, don't make of such an accident a thing
bigger than it is.
</water>
--
gentoo-dev@gentoo.org mailing list

Francesco Riosa wrote:
> <water>
> Sometimes happen to write lines of code not well written, not clear and
> still working.
> Simply that, sometimes happen, don't make of such an accident a thing
> bigger than it is.
> </water>

The "problem" is that they ignore polite bugreport *with* attached solution.

I hope my post didn't seem like "PHP is a piece of crap", it's agreat
software, of course.

-jkt

--
cd /local/pub && more beer > /dev/mouth

Jan Kundrát wrote:

>Omer Cohen wrote:
>
>
>>we're talking about one of the biggest OC communities.
>>
>>
>
><flame>
>...and the same community whose members write code like that described
>in PHP's bug 31261 [1], which seems quite ugly, at least to me.
></flame>
>
>My point is that even if developers say their code is stable, it doesn't
>have to mean it *really* is, altough they're probably correct.
>
>[1] http://bugs.php.net/bug.php?id=31261
>
>
>
Actually, I can understand avoiding unnecessary bit flipping. I've done
that in databases on occasion. I'll write a SQL statement that checks
if there are matching records for an update instead of just executing a
statement that makes changes to those matching records. Depending on
the likelihood of changes and the number of records to be changed, it
was sometimes faster to pre-qualify an update instead of just doing it
when it wasn't going to find any matches.

That's all the code in that particular bug does, check the value of a
bit before turning it off. If it's already off, don't touch it.
--
gentoo-dev@gentoo.org mailing list

D. Wokan wrote:
> Actually, I can understand avoiding unnecessary bit flipping. I've done
> that in databases on occasion. I'll write a SQL statement that checks
> if there are matching records for an update instead of just executing a
> statement that makes changes to those matching records. Depending on
> the likelihood of changes and the number of records to be changed, it
> was sometimes faster to pre-qualify an update instead of just doing it
> when it wasn't going to find any matches.

Yep, but we're talking about C code, not about SQL queries. I'd of
course accept this explanation if it came from PHP devs at bugzilla, but
they didn't bother, which made me a bit surprised.

And BTW, talking about speed - setting open_basedir is quite common
among webhosters, so I think the code suggested in that bugreport will
be faster in most cases.

-jkt

--
cd /local/pub && more beer > /dev/mouth

maillog: 24/04/2005-11:00:54(+0200): Jan Kundrát types
> D. Wokan wrote:
> > Actually, I can understand avoiding unnecessary bit flipping. I've done
> > that in databases on occasion. I'll write a SQL statement that checks
> > if there are matching records for an update instead of just executing a
> > statement that makes changes to those matching records. Depending on
> > the likelihood of changes and the number of records to be changed, it
> > was sometimes faster to pre-qualify an update instead of just doing it
> > when it wasn't going to find any matches.
>
> Yep, but we're talking about C code, not about SQL queries. I'd of
> course accept this explanation if it came from PHP devs at bugzilla, but
> they didn't bother, which made me a bit surprised.

Don't be surprised. The exactly same explanation is at the bugreport
that you linked to in your last e-mail. I don't know if it is a php dev
who made it, but the address is @php.net. Here is the exact text:

[23 Dec 2004 7:06pm CET] iliaa@php.net

This is a non issue, the code avoids touching the mask if there
is nothing to change in it.

> And BTW, talking about speed - setting open_basedir is quite common
> among webhosters, so I think the code suggested in that bugreport will
> be faster in most cases.
>
> -jkt
>
> --
> cd /local/pub && more beer > /dev/mouth

--
() Georgi Georgiev () * Knghtktty is not going to ask how ()
() chutz@gg3.net () zucchini got into the discussion ... ()
() +81(90)6266-1163 () ()

On Friday 22 April 2005 23:26, Omer Cohen wrote:
> I've been working with it since it came out.
>
> And I made big projects with more then a few classes and objects and it all
> worked fine, I didn't have any problems with it.
> It's not like a group of 100 people from microsoft tested it and said it's
> ok, the entire community of PHP developers agreed it's alright and aprooved
> it.
> we're talking about one of the biggest OC communities.
>
> I believe it's stable enough to get marked as stable on the portage tree.
>
> Regarding the remark of not overriding the system, what I ment is that I
> there's no reason to manualy unmask a stable product..

I strongly agree. We actually lost a client recently because we adhere to the
stable tree of Gentoo but our PHP was too dated for them (they wanted PHP
5.x).

Cheers,
--
Casey Allen Shobe | SeattleServer, Inc.
cshobe@seattleserver.com | cell 425-443-4653
http://www.seattleserver.com
--
gentoo-dev@gentoo.org mailing list

On Sun, 24 Apr 2005 15:43:10 +0000 Casey Allen Shobe - SeattleServer
Mailing Lists <lists@seattleserver.com> wrote:
| I strongly agree. We actually lost a client recently because we
| adhere to the stable tree of Gentoo but our PHP was too dated for
| them (they wanted PHP 5.x).

See, this is why we have /etc/portage/...

--
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

On Sun, Apr 24, 2005 at 03:43:10PM +0000, Casey Allen Shobe - SeattleServer Mailing Lists wrote:
> On Friday 22 April 2005 23:26, Omer Cohen wrote:
> > I've been working with it since it came out.
> >
> > And I made big projects with more then a few classes and objects and it all
> > worked fine, I didn't have any problems with it.
> > It's not like a group of 100 people from microsoft tested it and said it's
> > ok, the entire community of PHP developers agreed it's alright and aprooved
> > it.
> > we're talking about one of the biggest OC communities.
> >
> > I believe it's stable enough to get marked as stable on the portage tree.
> >
> > Regarding the remark of not overriding the system, what I ment is that I
> > there's no reason to manualy unmask a stable product..
>
> I strongly agree. We actually lost a client recently because we adhere to the
> stable tree of Gentoo but our PHP was too dated for them (they wanted PHP
> 5.x).
5.x is in portage since many months. Just use keywords. Just
customize. Even brand-new Redhat Enterprise 4.0 provides 4.3.9-x only.


funnily enough the PHP Guys recommended Apache 1.3 only for a long time.

Jürgen
--
gentoo-dev@gentoo.org mailing list

Hello

> funnily enough the PHP Guys recommended Apache 1.3 only for a long time.

I've been using Apache 2 and PHP (CGI due to suEXEC) for more than two
years now on a public webserver. It've never expierenced any
instabilities.

Greets,
Michael

--
Gentoo Linux Developer using m0n0wall | http://hansmi.ch/
news: gotcha

On 4/24/05, Michael Hanselmann <hansmi@gentoo.org> wrote:
> Hello
>
> > funnily enough the PHP Guys recommended Apache 1.3 only for a long time.
>
> I've been using Apache 2 and PHP (CGI due to suEXEC) for more than two
> years now on a public webserver. It've never expierenced any
> instabilities.
>

I don't remember the details, but there were a number of addon
products that were quite slow in coming to grips with Apache 2. Also,
there are a number of products that don't play well with PHP5. The
more plain jane your code the less likely you'll have problems with
either.

--
Collins
When I saw the Iraqi people voting three weeks ago, 8 million of them,
it was the start of a new Arab world.... The Berlin Wall has fallen.
- Lebanese Druze leader Walid Jumblatt

--
gentoo-dev@gentoo.org mailing list

The thing is, that while there's thew newest version (5.0.4) which had
all/most of the bugs fixed since 5.0, the original 5.0 version is still
being "tested".

I think that after 5.0 was released you should have waitied for about a
month or so to let people discover bugs like they did, and released
patches/updates.
5.0.4 has been stable for quite a while, meaning most of the major things
are fixed if not all of them.
So atleast add it to the tree, if not stable then atleast masked.

On 4/25/05, Duncan <1i5t5.duncan@cox.net> wrote:
>
> Omer Cohen posted <30e61698050422051322736ee3@mail.gmail.com>, excerpted
> below, on Fri, 22 Apr 2005 14:13:51 +0200:
>
> > PHP 5.0 was released a long time ago, and alot of fixes and patches were
> > released after it to make sure it's sable.
> >
> > According to PHP.net <http://PHP.net> <http://php.net/> the stable
> versions are PHP 5.0.4 &&
> > 4.3.11
> > 4.3.11 is marked stable, but 5.0.4 dosn't even exist on the tree.
> >
> > 5.0.0 isn't marked at all, and everything till 5.0.3-r2 is marked are
> hard
> > masked and still being tested.
> >
> > It's been like this for a long time now.
> >
> > As a PHP developer I believe that 5.0.4 is more then stable, and should
> be
> > added and marked stable.
> >
> > I don't wanna override the system and install it manualy.
>
> OK, I see a big discussion, but nobody has yet made this point, directly
> at least, so here it is...
>
> I agree that 5.0.4 should at least be in the tree, if upstream is calling
> it stable.
>
> The point that should be emphasized, however, is that there's a /big/
> difference between the upstream application being "stable", and Gentoo's
> particular instance, that is, the ebuild script that merges it onto a
> Gentoo system, being stable. Gentoo's keywording, while somewhat
> correlating with upstream in that what upstream has declared a beta or RC
> is often never arch-stable keyworded on Gentoo, generally serves to
> indicate the Gentoo ebuild maintainer's evaluation of the stability of the
> EBUILD, *NOT* the stability (or lack thereof) of the upstream source.
>
> Thus, as I said above, yes, the version that upstream calls "stable"
> should reasonably be expected to be in the portage tree in some form
> within a reasonable (few week, often less) time, however, one can't always
> expect that said portage tree version will be marked stable just because
> upstream defines that particular version of their product as stable,
> because the status of the Gentoo instance of it, the ebuild, may itself
> not be stable, on one or more archs, possibly on all of them.
>
> In this instance, >=php-5.0 on Gentoo is hard masked, not because of what
> upsteam says, but because (presumably) there have been and remain
> unresolved issues with the Gentoo deployment. Something in Gentoo's
> previous deployments conflicts with the current 5.0 layout, and a smooth
> transition hasn't yet been worked out and fully tested, so the 5.x series
> remains hard masked.
>
> Ignoring for the moment the issue of the 5.0.4 upstream-stable version
> itself not being in the tree at all, if a sysadmin is suitably comfortable
> with php-5.x, and either understands the issues keeping it masked on
> Gentoo and knows they don't apply in his case or at least is willing to
> extend the effort to work around any issues that may appear, said sysadmin
> is entirely free to package.unmask, or add keywords in an overlay, as
> appropriate. That's why the portage system has been designed with that
> flexibility in place, after all -- so it can be used at the decision of
> the individual Gentoo user -- aka the local Gentoo system sysadmin.
>
> --
> Duncan - List replies preferred. No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." Richard Stallman in
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
>
>
> --
> gentoo-dev@gentoo.org mailing list
>
>


--
Thanks,
Omer Cohen
www.omerc.net <http://www.omerc.net>
omerc.net@gmail.com

Omer Cohen posted <30e61698050422051322736ee3@mail.gmail.com>, excerpted
below, on Fri, 22 Apr 2005 14:13:51 +0200:

> PHP 5.0 was released a long time ago, and alot of fixes and patches were
> released after it to make sure it's sable.
>
> According to PHP.net <http://php.net/> the stable versions are PHP 5.0.4 &&
> 4.3.11
> 4.3.11 is marked stable, but 5.0.4 dosn't even exist on the tree.
>
> 5.0.0 isn't marked at all, and everything till 5.0.3-r2 is marked are hard
> masked and still being tested.
>
> It's been like this for a long time now.
>
> As a PHP developer I believe that 5.0.4 is more then stable, and should be
> added and marked stable.
>
> I don't wanna override the system and install it manualy.

OK, I see a big discussion, but nobody has yet made this point, directly
at least, so here it is...

I agree that 5.0.4 should at least be in the tree, if upstream is calling
it stable.

The point that should be emphasized, however, is that there's a /big/
difference between the upstream application being "stable", and Gentoo's
particular instance, that is, the ebuild script that merges it onto a
Gentoo system, being stable. Gentoo's keywording, while somewhat
correlating with upstream in that what upstream has declared a beta or RC
is often never arch-stable keyworded on Gentoo, generally serves to
indicate the Gentoo ebuild maintainer's evaluation of the stability of the
EBUILD, *NOT* the stability (or lack thereof) of the upstream source.

Thus, as I said above, yes, the version that upstream calls "stable"
should reasonably be expected to be in the portage tree in some form
within a reasonable (few week, often less) time, however, one can't always
expect that said portage tree version will be marked stable just because
upstream defines that particular version of their product as stable,
because the status of the Gentoo instance of it, the ebuild, may itself
not be stable, on one or more archs, possibly on all of them.

In this instance, >=php-5.0 on Gentoo is hard masked, not because of what
upsteam says, but because (presumably) there have been and remain
unresolved issues with the Gentoo deployment. Something in Gentoo's
previous deployments conflicts with the current 5.0 layout, and a smooth
transition hasn't yet been worked out and fully tested, so the 5.x series
remains hard masked.

Ignoring for the moment the issue of the 5.0.4 upstream-stable version
itself not being in the tree at all, if a sysadmin is suitably comfortable
with php-5.x, and either understands the issues keeping it masked on
Gentoo and knows they don't apply in his case or at least is willing to
extend the effort to work around any issues that may appear, said sysadmin
is entirely free to package.unmask, or add keywords in an overlay, as
appropriate. That's why the portage system has been designed with that
flexibility in place, after all -- so it can be used at the decision of
the individual Gentoo user -- aka the local Gentoo system sysadmin.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

Omer Cohen posted <30e61698050425063334d003e9@mail.gmail.com>, excerpted
below, on Mon, 25 Apr 2005 15:33:08 +0200:

> 5.0.4 has been stable for quite a while, meaning most of the major
> things are fixed if not all of them.
> So atleast add it to the tree, if not stable then atleast masked.

Absolutely agreed. I haven't seen anyone here disagree with that. I'd
guess the reason it hasn't been done, therefore, has more to do with the
overload factor, at least in that herd, of what are after all volunteer
developers, than anything else. Some herds and areas of the portage tree
are even more understaffed than Gentoo is as a whole, and it just hasn't
gotten done.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list