SitePoint Sponsor

User Tag List

View Poll Results: How would you rate the response and follow-up on PHP bug reports?

Voters
83. You may not vote on this poll
  • Excellent

    4 4.82%
  • Fine

    5 6.02%
  • OK; no worse than could be expected

    3 3.61%
  • Frustrating

    13 15.66%
  • Awful

    11 13.25%
  • I've never reported a bug in PHP

    47 56.63%
Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 53
  1. #26
    Mlle. Ledoyen silver trophy seanf's Avatar
    Join Date
    Jan 2001
    Location
    UK
    Posts
    7,168
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My favourite response to a PHP bug report in recent times is:

    Quote Originally Posted by http://bugs.php.net/bug.php?id=34196
    You either have broken system or you're doing something stupid. There's nothing wrong with this.
    Of course it got marked a bogus too

    Sean
    Harry Potter

    -- You lived inside my world so softly
    -- Protected only by the kindness of your nature

  2. #27
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ... much later ...

    That is classic.

  3. #28
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think part of the problem is one man's design feature is another man's bug.

    In particual, I believe the most recently inspired bug report was a $var =& $this, which works fine in php 4.3.*, 4.4.*, 5.0.* and is PHP Fatal in 5.1.0. I think (from remembering talk about this on the php-dev list) that this was done to fix a potental memory leak problem, which is a "good thing" TM. The problem is, it creates a near catch22 situation for a developer who wants to continue to mainatain their PHP4 compatable libraries. From the PHP4 developers perspective, this is an unwanted significant BC break, whereas someone who is developing in or writing code for HEAD it is a significant clean up of an internal PHP engine issue and very is desireable.

    Probably the more immediate issue is that a "bogus bug, RTFM" comment does not address the heart of the issue, but how much time do you want people to spend creating clear, eduacation, bug closure issues vs. actual time spent out trying to fix bugs? (plus my memory could be bad and I might be completely off base on this issue). Not an easy call from any direction or perspective

    The other issue I have with the tone of this thread in general is to cast Zend the corporation as the owners of PHP. There are certainly many active PHP developers outside of Zend who have a great impact on the process. Watching the internals list, you can see that Zeev and Andi have a significant voice in the issue, but it is not an overriding one. If we substitute "PHP Group" for "Zend" in most of the comments above it comes closer to the truth.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  4. #29
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    True, but not always a viable option, financially or otherwise.
    If you can't afford to pay for support then you have options. Fix it yourself or solicit someone else in the community to fix it for you; however, biting the hand that feeds you by criticizing the free work that they do for you is probably not going to get you very far. Agreed?

    By-the-by: have any of you reported bugs on other large projects? It works about the same way as it does in PHP. Look at Linux -- there is the plain vanilla kernel that some prefer to use and then there are certain issues and bugs that are only addressed in other trees, for example Red Hat's or Suse's or Ubuntu, etc. Some of these will never make it into mainline but because they are of interest to specialized groups, others have undertaken efforts (including paid-for effort) to maintain their own branches. This is FOSS at work. Zend doesn't own PHP anymore than Linus owns Linux. They are the main centers of gravity for each group and that is important. Yet we all have freedom.

    Sure, sometimes a bug that is listed as bogus in PHP is still important to the person or people that reported it; however, unless they have the means to do something about it, they really have no standing to complain about it because you can't dictate what someone else should do. Sometimes having the means to do something about is as straightforward as building an alternative community around your issue. Look at the Hardened PHP project -- this is precisely what they do. It takes effort but if you aren't willing to take the effort and you can't pay for it, why should someone else take it up on your behalf, particularly when they don't agree with you?

    Please -- report bugs and work patiently with the QA team and developers to help make PHP better for everyone. Don't be discouraged if your proposals aren't dealt with adequately at first blush. If there truly is merit to it or a wider interest, there may still be a way to work through the issue.

  5. #30
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    I think we are all having a go at what we see as mismanagement.

    If they just left legitimate and serious bugs open, rather than closing them as bogus regardless, that would go a long way to build goodwill. It would also give an accurate idea of the real state of the PHP code base. I have no idea at what point I can trust a move to PHP5.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  6. #31
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, at the moment my hosting is using PHP5.0.3 and likewise I have this on my PCs, but I feel I need to install a newer version, what is stopping me at the moment is my host is holding back on the upgrade

    I need to install a newer version so I know my scripts don't break, but I ain't going to the trouble until I know it's going to be worthwhile.

    At the moment, it doesn't look like that.

  7. #32
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    If you can't afford to pay for support then you have options. Fix it yourself or solicit someone else in the community to fix it for you; however, biting the hand that feeds you by criticizing the free work that they do for you is probably not going to get you very far. Agreed?
    While I understand what you are saying, I disagree that criticizing is 'biting the hand the feeds you'. While it may be easier to criticize than to fix, it is still helpful. By criticizing, you may be lucky enough to encourage someone to fix something. In an ideal world, we would all be able to help out and not rely on anyone. But we don't all have relative skills to fix bugs ourselves, or the neccessary funds to pay someone else to do it, or even the time to do it.

    The QA team was setup in the first place because of criticizism:
    Quote Originally Posted by http://ie2.php.net/manual/en/history.php.related.php
    The PHP Quality Assurance Initiative was set up in the summer of 2000 in response to criticism that PHP releases were not being tested well enough for production environments.
    So it is not like it critizism is completely ignored, or doesn't bring anything good (whether or not you deem the QA team good is subjective).

  8. #33
    SitePoint Addict chiefmonkey's Avatar
    Join Date
    Aug 2002
    Posts
    207
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is an interesting thread.

    First of all I think one of the main problems is that many PHP developers are self-taught and therefore do not have the correct skills (yet) to dive into C and fix bugs. Therefore they rely on others to fix the bugs for them, which also means the PHP community is at the mercy of the people who do have the skills.

    Secondly, I find the PHP interals list and those on it to be rather, well scary. The general atmosphere on the list can be rather unpleasant at times. I have done a large amount of C at university and I don't think I would be willing to submit any bug fixes simply because of this. There was even a discussion on internals, a PHP 6 wishlist, and I still couldn't bring myself to post, it appears to me there are people waiting to shoot you down. I am sure there are many other people like me.


    I agree with the previous thread who pointed out that PHP belongs to the community, and I think the community would be willing to help if the process was a bit more open.

    George
    Got Sig!

  9. #34
    SitePoint Member
    Join Date
    Jun 2005
    Location
    Moscow, Russia
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hm... I have different experience.
    Many times I sent bugs. Half (or more) of they were "bogus" and PHP guys described me my faults. They were right
    But really bugs were fixed immediately

  10. #35
    SitePoint Addict pachanga's Avatar
    Join Date
    Mar 2004
    Location
    Russia, Penza
    Posts
    265
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by chiefmonkey
    Secondly, I find the PHP interals list and those on it to be rather, well scary. The general atmosphere on the list can be rather unpleasant at times. I have done a large amount of C at university and I don't think I would be willing to submit any bug fixes simply because of this. There was even a discussion on internals, a PHP 6 wishlist, and I still couldn't bring myself to post, it appears to me there are people waiting to shoot you down.
    I totally agree You need to wear a kevlar vest and helmet before posting anything to internals...

  11. #36
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    It is far more naive to assume that someone who has already provided something for you to use in an open and free way is also obligated to make sure it does everything you want it to and without error and within the timeframe and parameters that you set. It is also naive to think that the community does not want to help.
    I don't think they have an obligation to make new features. But they should fix the bugs in the ones they have already provided. That should be the higher priority.
    Quote Originally Posted by jayboots
    The fact that some people seem to be advocating not reporting bugs because they have not got what they feel to be adequate traction for some of the issues they reported is irresponsible and rather disheartening to see in a professional forum.
    Personally, I'm not advocating anything. I posted the poll because I wanted to get some impression of whether my own harrowing experience was just bad luck or part of a pattern.

    It is a genuine question for me: do the PHP developers really want bug reports from us "outsiders"? If the answer is no, then obviously I would advocate not reporting bugs. If the answer is yes, then they need to change their attitude from "you should be grateful we fix these bugs for you" to "you're helping us by finding and reporting bugs; we're helping you by fixing them".
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  12. #37
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    Sure, sometimes a bug that is listed as bogus in PHP is still important to the person or people that reported it; however, unless they have the means to do something about it, they really have no standing to complain about it because you can't dictate what someone else should do. Sometimes having the means to do something about is as straightforward as building an alternative community around your issue. Look at the Hardened PHP project -- this is precisely what they do. It takes effort but if you aren't willing to take the effort and you can't pay for it, why should someone else take it up on your behalf, particularly when they don't agree with you?
    I'm not sure this has anything to do with reality. The bug I reported was the fact that PHP 5 object references--the very heart of the PHP 5 object model--were not serialized in sessions. Zend is supposedly "driving PHP to the enterprise" and I have to spend half a year convincing them that something like that is a bug worth fixiing?

    Edit: just one more thing. These attitudes are self-fulfilling prophecies. By falsely labeling bugs as bogus, you punish the people who have taken the time to meticulously isolate and report the bug properly. The ones who don't take the time don't care; they didn't lose anything except the few minutes to file the bug report. The likely result of this practice is that the average quality of the bug reports goes down.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  13. #38
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    I'm not sure this has anything to do with reality. The bug I reported was the fact that PHP 5 object references--the very heart of the PHP 5 object model--were not serialized in sessions. Zend is supposedly "driving PHP to the enterprise" and I have to spend half a year convincing them that something like that is a bug worth fixiing?
    I don't know your bug but as sweatj said, sometimes a "bug" is a really a feature and sometimes a bug report is really a feature request. I just don't think it is appropriate to play the "is PHP ready for the enterprise" card when your particular issue is not addressed for you. Still, I appreciate the frustration you must feel.

    Quote Originally Posted by dagfinn
    Edit: just one more thing. These attitudes are self-fulfilling prophecies. By falsely labeling bugs as bogus, you punish the people who have taken the time to meticulously isolate and report the bug properly. The ones who don't take the time don't care; they didn't lose anything except the few minutes to file the bug report. The likely result of this practice is that the average quality of the bug reports goes down.
    This reminds me of he-said, she-said. They say it is bogus, you say it is falsely called bogus. Who is right? The development and QA team or you? Sure there are going to be false positives -- everyone makes mistakes and sometimes technology is subtle and difficult to see, even for people who hack on the codebase. I would still wager that the vast majority of bugs listed as bogus ARE bogus. Furthermore, why do you characterize it as punishment? They disagreed with you -- are you just objecting to the term "bogus"? This isn't personal you know. If you think it is important, keep the discussion with them going (btw: 6 months is rather quick compared to some "corporate" procedures I've lived through). Not doing so really leaves one thinking that maybe it was bogus after all.

    One thing I noticed is that there appears to be a lot of friction generated by the character or responses that bug reporters recieve. I wonder if people would feel more appeased if certain labels were changed. Instead of "bogus" would, "inapplicable" or "non-conforming" -- or perhaps a few other labels -- be better? Instead of "Won't fix" (which often relate to BC issues or deal with sensitive code areas) would something like "as-is behaviour required" be better?

    Well, looking back I've taken a much stronger stance than I would have liked. I hope I haven't pissed anyone off. The thing is, I think it is unfair to have a moan session at the expense of the devs and QA team over this because I really think they DO CARE and that they take on a really challenging and unnappreciated role -- we all know that bugs aren't fun for anyone. I also tend to think that in balance, they are doing a fair job.

  14. #39
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by jayboots
    I don't know your bug but as sweatj said, sometimes a "bug" is a really a feature and sometimes a bug report is really a feature request.
    I haven't replied to any of your posts yet, because you comments don't seem to match up with any software engineering reality I have ever experienced. However you seem to be going increasing off the rails. The bugs I have reported have involved server crashes. How is a server crash a "feature"?

    Quote Originally Posted by jayboots
    They say it is bogus, you say it is falsely called bogus. Who is right? The development and QA team or you?
    It's not a matter of opinion usually. You can simply appeal to the facts on a case by case basis. Such as failed code and so on. Often serious bugs closed as bogus have a dozen or more suporting comments before being closed, often replications of the bug.

    Similarily a crash (rather than a fatal error) or a fatal error on syntactically correct code are bugs pure and simple. No escaping that one.

    Have a look in the bug tracker for language level bugs. It won't take you long to find some real howlers.

    Quote Originally Posted by jayboots
    I would still wager that the vast majority of bugs listed as bogus ARE bogus.
    They're not the ones being discussed here. It's the serious language level ones. Most of the members of this forum won't be submitting bugs like that.

    Quote Originally Posted by jayboots
    This isn't personal you know.
    No one is characterising this as personal. We are discussing whetehr it borders on unprofessional. A perfectly valid discussion, and an important one for the longevity of PHP.

    Quote Originally Posted by jayboots
    If you think it is important, keep the discussion with them going
    You can't. They've been closed remember.

    Quote Originally Posted by jayboots
    Not doing so really leaves one thinking that maybe it was bogus after all.
    As you admit you haven't actually looked at any of them, how would you know?

    Quote Originally Posted by jayboots
    I wonder if people would feel more appeased if certain labels were changed.
    It would if they referred to them as "open".

    Quote Originally Posted by jayboots
    Well, looking back I've taken a much stronger stance than I would have liked. I hope I haven't pissed anyone off.
    Well, you got my hackles up and I wasn't even quoted by you...

    Quote Originally Posted by jayboots
    The thing is, I think it is unfair to have a moan session at the expense of the devs and QA team over this because I really think they DO CARE and that they take on a really challenging and unnappreciated role -- we all know that bugs aren't fun for anyone. I also tend to think that in balance, they are doing a fair job.
    I would agree except for the "fair job" part. A volunteer is not necessary doing a good job by nature of them volunteering. They may be doing a "worthy" job as best they can, but that's not the same thing. They are doing a worthy job, but not an enterprise quality one.

    No one is criticising the PHP folk personally (remember), simply their development practices regarding bugs. Their process is broken and they are cutting corners. Marking bugs as bogus pretty much in face of reality helps no one. least of all them long term.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  15. #40
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    This reminds me of he-said, she-said. They say it is bogus, you say it is falsely called bogus.
    It's he-said, she-said among the members of this forum. Some of us have been there; I can understand that some who haven't are skeptical. There's not much point in discussing that much further, and I don't want to spend time pleading my particular case; let me just make it clear that that particular bug is no longer "bogus", it's fixed. But I had to break in through a back door to achieve that.
    Quote Originally Posted by jayboots
    Who is right? The development and QA team or you?
    I didn't talk to a development and QA team. I talked to a single email pseudonym which I assume represents a single person.
    Quote Originally Posted by jayboots
    Furthermore, why do you characterize it as punishment? They disagreed with you -- are you just objecting to the term "bogus"? This isn't personal you know.
    I'm objecting to the time I wasted on it--many hours, even days. I mean wasted--they could easily have fixed it based on the first report. And I'm using the term "punishment" mainly to point out that it is sure to shape the behavior of bug reporters, discouraging the more serious ones primarily.
    Quote Originally Posted by jayboots
    If you think it is important, keep the discussion with them going (btw: 6 months is rather quick compared to some "corporate" procedures I've lived through). Not doing so really leaves one thinking that maybe it was bogus after all.
    That illustrates what I mean by self-fulfilling prophecies. If they keep insisting it's bogus until the bug reporters give up, they can keep their belief in the prevalence of bogus bug reports.
    Quote Originally Posted by jayboots
    The thing is, I think it is unfair to have a moan session at the expense of the devs and QA team over this because I really think they DO CARE and that they take on a really challenging and unnappreciated role -- we all know that bugs aren't fun for anyone. I also tend to think that in balance, they are doing a fair job.
    You may be right; I'm not trying to judge their work in general. But I do think we're discussing a real problem, and my best guess is that it is an ugly side-effect of a culture of fear. As chiefmonkey said: "I find the PHP interals list and those on it to be rather, well scary."
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  16. #41
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    I do think we're discussing a real problem, and my best guess is that it is an ugly side-effect of a culture of fear. As chiefmonkey said: "I find the PHP interals list and those on it to be rather, well scary."
    Hi Dagfinn. I think I get where you are coming from, but I don't really see the point of this. Okay, the internals list can be rather direct -- but what does that have to do with bug reporting? What's with the "ugly side-effect" and "culture of fear" comments?

    I am suspicious of the motives behind this thread: it is a poll that asks about the competence (or lack thereof) of the bug reporting team/system and to what end? To develop some form of quasi statistic? Wouldn't it have been more constructive to have rather had a "how can we make the bug reporting process more pleasant and effective" type of poll/thread? After all, you do have a point -- things can be better.

    Well, I've had more than my fair say.

    Best Regards.

  17. #42
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mx2k
    :::kicks jayboots soapbox out from under him:::

    no offense, but zend is taking the roll of deciding what goes in the offical build of php and is trying to capitalize on php by selling it off as an enterprise ready language.

    Not to mention, that even if you did impliment a fix and compiled it, its only on your server, that is, if you can afford a server otherwise your stuck with shared hosting and i'm sure all those hosting companies will let you fix problem and up load your version of php ......

    so if its an enterprise ready language where is the enterprise ready support to fix those bugs so they can put their money where their advertising (mouth) is and sell those enterprise php platforms?

    and if you do fix something, they would still have to go through the code, test it themselves and agree to impliment it. If someone else was fixing your code, wouldn't you be a little skeptical before implimenting it just to be on the safe side?
    You've never submitted a patch for PHP, I see?

    The patching process usually goes like this:

    1.) You submit a patch

    2.) If nobody objects to it, the maintainer of that portion of code implements it.

    I've submitted several patches. Most of them were applied, and the ones that aren't were irrelevant by the time I submitted them (problem already fixed / feature already implemented).

    (By the way, you, too, can become a developer, if you'd really like. OS isn't about using free software and making a dime on someone else's labor, it's about being part of a community -- and contributing.)

    About 9 out of 10 of the bugs reported (and they keep EVERY report there -- go look for yourself) get reported as "bogus" because they only occur on a specific platform under specific circumstances -- typically not something that can easily be tested. If you're experiencing a bug that isn't experienced by a significant portion of the user base, the odds are extremely high that it's not going to get that high of a priority to fix. From my best estimates, there are roughly 2 dozen active developers on the PHP project (might be more, dunno), and maybe another 2 dozen frequent contributors who aren't "core developers". If you'd like to explain to me how 2 dozen developers are going to fix every single bug that occurs on every platform with 0 financial support, I'd love to hear it.

    They're not the ones being discussed here. It's the serious language level ones. Most of the members of this forum won't be submitting bugs like that.
    If language-level bugs were that much of an issue, the language wouldn't be used by as many people it is.

    Here are all the bogus reports

    Note:

    1.) Of all PHP bugs in the DB, only about a third are flagged "bogus" (about 10k total; 18k have been resolved, and there are an additional 2k or so currently being worked on or recently submitted)

    2.) Of the bogus bugs, more than half are duplicates

    3.) Of the remainder, the majority relate to server misconfigurations, feature requests, and things that are just the way that PHP works (regardless of whether you like it or not).

    I submitted a bug last night and it was resolved this morning. Crazy.

    On the other hand, the last time I submitted a bug to Microsoft for their developer tools (this was for MS Visual FoxPro, about 4 years ago; that was the last time I worked with MS developer tools that I actually was able to receive support for in the first place...), they charged my company $150 for the call, never fixed the bug, and then proceeded to tell us that they didn't issue refunds for any reason (eventually we got ahold of a CSR manager who agreed that they would refund the fee since it was an actual bug).

    Now, this isn't to say that PHP's bug reporting system is perfect. There's simply no such thing. But I strongly suspect that the majority of the complaints stem from isolated, personal cases, and from people who like to label everyone else's mistakes as incompetence. I see the exact same types of complaints about Java, C#, and just about every other language that has a significant number of developers who work with it every day.

    And, of course, the ever popular "if...wants to be enterprise ready" arguments are continually amusing. Enterprises are already using it. I'm pretty sure that developers choosing to use PHP for enterprise development are more qualified to determine if the project is ready for enterprise development than anyone else.

  18. #43
    SitePoint Zealot
    Join Date
    Feb 2003
    Posts
    156
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think 3 other things might be worth poiting out:

    - some people see the bug-tracker as the place where the discussion about bugs should be going on, and feel censored when a bug is closed. Obviously that's not how everybody is using bugtrackers, and it is my impression that the PHP people aren't either. Well, given that there are mailing-lists for developers, I am not sure that closing a bug is the same thing as trying to shut the people up. Of course a bug-tracker is a communication tool, but it only goes so far.

    - A lot of the people seem to be upset about the same issues. If anything, this seems to make it more understandable why they would close the bugs relatively quickly: Because the issue was already talked about a lot, and you can't have the same detailed discussion everytime someone reports the same issue. Of course I am not saying that people should stop bringing them up, it's just that the bugtrakcer might be the wrong place to do these discussions.

    - And lastly, I am sure a lot of people here have professional experience, however managing/supporting something for a small and closed customer base is completely different than managing/supporting something for a really large userbase and open to anyone. As a developer you have to get somewhat numb and learn to ignore a lot (of assholes) - other wise you end up going completely and utterly nuts. That's a reality. The type of bull**** you are confronted with on a daily basis leaves its marks.
    So with all due respect, but when people here are saying how they would all handle it better, I doubt they are incorporating this effect into their equations. I'm sure it's easy to do it better for a few days or weeks, but try doing it better than that for years, and you'll find out your attitude will change, too.

  19. #44
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    I am suspicious of the motives behind this thread: it is a poll that asks about the competence (or lack thereof) of the bug reporting team/system and to what end? To develop some form of quasi statistic?
    To figure out what the problem is and what the causes of it might be. Didn't that possbility occur to you?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  20. #45
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    Wouldn't it have been more constructive to have rather had a "how can we make the bug reporting process more pleasant and effective" type of poll/thread? After all, you do have a point -- things can be better.
    Ignoring the issue of whether "we" have the power to do something about it, here are some suggestions:
    • Embrace the belief that quality is free .
    • Practice mutal respect between bug reporters and bug fixers.
    • Ensure sufficient test coverage of all features.
    • Encourage testing and bug reporting in beta versions in particular.
    • Make sure those who make decisions about the status of bugs have sufficient understanding of relevant features.

    Either one of those would probably have made a radical difference to my bug reporting experience.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  21. #46
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @dagfinn: the poll didn't suggest that the reason was to help make the process better (ie: what is the problem and what are the causes). It wasn't phrased that way and the response it generated was more of the basic b*tching that one would expect. So, no, I didn't think that was a possibility.

    I do happen to think that in a FOSS project "we" always has power. There are really only two types of people in a FOSS project -- those who participate and those who do not. Of those who participate, the ones who participate the most and in the most positive ways are typically given the most leeway by the community. So "we" can make a difference by organizing and contributing something more than hot air. The points you made in your last point are good -- to me this is what the thread should have been about.

    - earlier I asked if the status labeling was causing unneccessary friction. I don't really see what you are getting at with the "mutual respect" point but maybe labeling speaks to a portion of that?

    - I am sure you are aware that there is already a large test-suite for PHP? Otherwise, just saying "ensure" is implying someone else should be making them more complete. You see the problem with that? It expects someone else to do work.

    - I also think that the last point doesn't really say much. The devs themselves are typically responding to bug reports. What more can you want in terms of competence? Besides, one could also say that a huge problem in the process is that the bug reporters are not sufficiently qualified to report bugs or even determine if a behaviour is a bug. Maybe if there was a step-by-step processes that helped qualify new bugs before they get entered into the system? Perhaps one on the dev-end as well to ensure that the right dev responds to the bug?

    I think that if we want to see a change, we will have to do some hard work and also be far more specific about the process.

    Greetings.

  22. #47
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For people who do not follow the internals mailing list, here is some more related discussion
    (and ouch, a bit more attitude in the referenced bug).
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  23. #48
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    @dagfinn: the poll didn't suggest that the reason was to help make the process better (ie: what is the problem and what are the causes). It wasn't phrased that way and the response it generated was more of the basic b*tching that one would expect.

    So, no, I didn't think that was a possibility.
    In my original post, I said "it would be interesting to know how representative these experiences are". It may not be "constructive" enough for you, but it's explicit that the goal is to get more information.

    You talk about b*tching, but I don't think that's fair; I don't think you can understand the problem without getting information about the symptom--the actual experiences people have had, good and bad.

    I didn't know ahead of time what the poll results would be. In fact, I don't pretend to know everything; the impression I get from you is that this mindset is surprising, even inconceivable.
    Quote Originally Posted by jayboots
    - earlier I asked if the status labeling was causing unneccessary friction. I don't really see what you are getting at with the "mutual respect" point but maybe labeling speaks to a portion of that?
    Above all, it's about respecting each others' time. The people who report the bugs and the ones who fix them are both volunteers and both are doing dirty work. It's not mutual respect when I spend hours isolating and reporting a bug and then someone spends a minute marking it "bogus".

    The text at bugs.php.net seems to imply just this kind of one-sided relationship between bug reporters and bug fixers.
    Quote Originally Posted by jayboots
    - I am sure you are aware that there is already a large test-suite for PHP? Otherwise, just saying "ensure" is implying someone else should be making them more complete. You see the problem with that? It expects someone else to do work.
    Not at all. You keep putting unfavorable interpretations on my statements. It's not about the work; it's about goals, commitment, consensus and communication. I reported a bug about a feature that was obviously meant to work, but it didn't. In fact, they had probably neglected to implement it. I could have contributed a test case for that--in fact I did. If there were a consensus that features like this should be covered by tests, they couldn't have just marked it bogus. If they thought I'd misunderstood the feature, they could have changed the test case to match their understanding of it. That would have been a much more useful way to communicate.
    Last edited by dagfinn; Sep 12, 2005 at 04:22.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  24. #49
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    In my original post, I said "it would be interesting to know how representative these experiences are". It may not be "constructive" enough for you, but it's explicit that the goal is to get more information.

    You talk about b*tching, but I don't think that's fair; I don't think you can understand the problem without getting information about the symptom--the actual experiences people have had, good and bad.
    Okay, I'll concede that point. Maybe it was just the way I read the poll question. Please know that it is not my intention to cast your statements in a bad light.

    Quote Originally Posted by dagfinn
    Above all, it's about respecting each others' time. The people who report the bugs and the ones who fix them are both volunteers and both are doing dirty work. It's not mutual respect when I spend hours isolating and reporting a bug and then someone spends a minute marking it "bogus".
    That's true but when I read that, it makes me think that you are characterizing the bug reporters as people who don't take the time to respond to bug reports -- ie. they don't care. You probably don't mean it that way, but that's what I see. We both know that these folks spend countless hours responding to bugs and as importantly, developing PHP in the first place. I'm not saying the response was appropriate in your case but looking at the bug reporting history, your case does not really seem typical to me. You have to admit, someone can spend 10 hours and more writing a bug report that someone more knowledgeable can immediately spot as being (for lack of a better word) bogus. Furthermore, the bug responder too can be wrong -- everyone can be.

    As time invested and merit are not the same thing, I think we ought be careful not to confuse the two. It is easy to get attatched to our labours -- this I think is natural and I agree that our efforts ought be respected. That shouldn't mean that it is verboten to disagree with one another and call things as we see them lest we offend someone's feelings. Unless I'm mistaken, though, you seem to be talking about the fact that you initially got little more than a form letter response rather than the fact that you disagreed with the response you got.

    Asides from all that, it does seem that it was unnecessarily difficult for you to get your point across to the bug team. Perhaps we can consider proposing some sort of a staged process:

    - the bug reporter submits with commentary
    - a bug responder replies with commentary but does not get to set status
    - the bug reporter can elect a status vote or can provide an ancillary response
    - the bug responder can elect a status vote or provide an additional reply
    - the bug status is voted on by the bug response team
    - changing the status of a bug voted in a particular way would require some sort of standard to be exceeded

    It does seem overtly formalized but perhaps it can help foster the idea of fairness (give-and-take) and slightly impartial review (voting).

  25. #50
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I think part of the problem is one man's design feature is another man's bug.

    In particual, I believe the most recently inspired bug report was a $var =& $this, which works fine in php 4.3.*, 4.4.*, 5.0.* and is PHP Fatal in 5.1.0. I think (from remembering talk about this on the php-dev list) that this was done to fix a potental memory leak problem, which is a "good thing" TM. The problem is, it creates a near catch22 situation for a developer who wants to continue to mainatain their PHP4 compatable libraries. From the PHP4 developers perspective, this is an unwanted significant BC break, whereas someone who is developing in or writing code for HEAD it is a significant clean up of an internal PHP engine issue and very is desireable.

    Probably the more immediate issue is that a "bogus bug, RTFM" comment does not address the heart of the issue, but how much time do you want people to spend creating clear, eduacation, bug closure issues vs. actual time spent out trying to fix bugs? (plus my memory could be bad and I might be completely off base on this issue). Not an easy call from any direction or perspective

    The other issue I have with the tone of this thread in general is to cast Zend the corporation as the owners of PHP. There are certainly many active PHP developers outside of Zend who have a great impact on the process. Watching the internals list, you can see that Zeev and Andi have a significant voice in the issue, but it is not an overriding one. If we substitute "PHP Group" for "Zend" in most of the comments above it comes closer to the truth.
    This is the thread that begins what will ultimately result in a lot of "WTF??" type complaints from people in the coming months:
    http://news.php.net/php.internals/16312

    I strongly encourage everyone and anyone who doesn't know why they decided to do the warning / notice / error thing with php references in 4.4 & 5.1.

    (Note: For the record, I do not feel that this should EVER be a fatal error as it is in 5.0.5. A warning (as it is in 4.4) -- absolutely! -- but a fatal error actually does, quite literally, break scripts that were working before. At least warnings could be trapped in well-written code. Putting in fatal errors is only going to replace the "unable to reproduce error" bugs with "OMG WHY IS MY SCRIPT BORKED?!?!?!").

    The problem, fundamentally, was that memory corruption (at the very core of the Zend engine itself -- in the memory manager) was occuring due to reference counting issues. TRULY fixing the problem will ultimately require a complete rewrite of the engine (again). This is bigger than the ZE1->ZE2 change. This will have ramifications on all php development going forward, and I certainly won't expect to see it come about until at least PHP6.

    Of course, the people who are going to experience the most frequent instances of this fix causing problems for them are those trying to maintain code bases for both php4 & php5. Personally, my projects that are 100% php5 are working fine with no special-case code, so it won't ultimately be a "huge" problem (just a slight annoyance in situations where you sometimes want to return a reference and sometimes don't -- something that you can no longer do at call time anyway).

    Now, as far as the attitude goes; I dunno, I've experienced it myself. When you give the SAME answer to the SAME questions THOUSANDS UPON THOUSANDS of times, you begin to get curt, offer copy-pasted answers, etc. Nobody has the time to write an essay explaining the reasoning behind why something was changed every single time somebody asks about it or reports it. The irony here, though, of course, is that the people who are generally the most polite with regards to bugs and whatnot are the Zend guys. It's the volunteers who tend to get short with people more than others. I can't recall seeing anything from Andi, Zeev, or even Rasmus (not technically a "zend guy", but close enough for historical reasons and his heavy involvement) be anything but polite.

    Personally, I'd be happy if the php group would just reply to these types of bugs with a link to a great big explanation of the problem. Problem solved.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •