Kristof Coomans wrote:
Hi Bertrand2010/7/28 Bertrand Dunogier<[email protected]>:2010/7/28 Kristof Coomans<[email protected]>2010/7/28 Björn Dieding<[email protected]>:I would say, they should be reopened.Well, please do, and update the affected version (see below).Betreff: [Sdk-public] Valid enhancement requests / issues being closed in the issue tracker Hi I am quite concerned that good and valid enhancement requests / issues (some examples: http://issues.ez.no/IssueView.php?Id=10489, http://issues.ez.no/IssueView.php?Id=14199) are currently being closed as won't fix or invalid because there was no feedback for a while. Is this the current policy? Best regards KristofNow I see issues being closed with this message: "eZ Publish has undergone a substantial rewrite in the transition from PHP4 to PHP5, which may invalidate old issues." This is IMHO a big lie. There did not happen a rewrite (http://en.wikipedia.org/wiki/Rewrite_%28programming%29) in the transition from PHP 4 to PHP 5. I understand you might want to close certain issues because you simply don't want to implement them, but please don't hide then behind such statements which are not correct.It's not really my role to answer that, but since we're facing an IssueGate affair here... We have 3 thousand open issues, including about 1000 that weren't updated since december 2007 (release date for 4.0). If we close all of these in an automated way, which is what we intend to do, we will be left with about 1400 issues to handle, and this is already more than we can handle. As said in the message, and that is the part I do believe you have removed when quoting us,I only quoted the part that really bothered me. I was myself very closely involved in the process of making eZ Publish compatible with PHP 5 (even initiated it in case you don't remember), and this had nothing to do with a "rewrite" like it is being called in the message I quoted.From the message it sounded like eZ Publish for PHP 5 has been buildfrom the ground up (to quote "rewrite" from wikipedia: the act or result of writing new source code to replace an existing program) and therefore the issues reported are probably not valid anymore because it is a new product, which is not true at all.we are perfectly okay with the authors, or anyone else, re-opening the issues if they are still considered valid. Now, we perfectly know that there hasn't been a big ass rewrite of eZ Publish since versions 3.x, but it still has undergone massive changes in many areas, and it is very likely that lots of issues are now invalidMassive changes only in the areas of WebDav, Mail and admin interface AFAIK, up to 4.3 (in eZ Publish itself, not taking eZ Systems extensions into account, the issues I am talking about have mostly nothing to do with them).I know some of them aren't, but if they are, just reopen them and update the affected versions.AFAIK regular issue reporters are not able to reopen any issue they are encountering. And the actual message was this: "open a new one against a currently supported version of eZ Publish if the issue can be reproduced on a new version of eZ Publish." So I would have to create a new issue for what was reported before and was not looked at properly by the development/support team? My point is that people won't bother anymore to create a new issue if they reported something a long time ago and there was never payed enough attention by eZ Systems to what they reported. Please, focus a bit more on quality than on quantity.
I will not voice for any of the particular issues that have been closed in the past days, but setting up a script to automatically close bugs that have been left in 'pending for feedback' state for a certain time is a widely accepted practice.
I even did the same on my own pet oss project, to keep the big list from growing beyond my capabilities of analysis and bug fixing: long lists of open bugs take away valuable time, as the developers spend their days browsing again and again through the same issues that have not enough information to be reproduced.
Otoh, as long as the closed issues are still findable via a simple search, and clearly marked as "cannot-reproduce" and not as "fixed", they still keep their value for developers and testers. Creating a new issue and linking it to an existing one should not be a daunting task - even though I agree that the possibility to simply reopen a closed bug would be even simpler.
Iirc, on php.net the close-issues-left-in-feedback-state interval is as low as 1 month... bye Gaetano
<<attachment: gg.vcf>>
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
