On 08.01.2017 at 07:46, Joe Watkins wrote:
> Some of you may have noticed that a few of us have put considerable effort
> into cleanup of pull requests on github, these are now manageable and I'm
> quite confident that we will be able to merge pull requests in a timely
> manner, and stay on top of it.
>
> When it comes to bugsnet, there are feature requests and bugs that have
> been open for more than 10 years, and nobody has talked about them in about
> as long, they may concern defunct versions of PHP, or removed extensions or
> SAPIs: These numbers in the thousands.
>
> It's very difficult (impossible) to see a good reason for these to be open,
> they are not useful at all.
>
> With normal support for 5 ended, now is the perfect time to cleanup
> bugsnet. If we can get the numbers down to something manageable, we have a
> reasonable expectation to stay on top of them.
>
> I think anyone that has been waiting a number of years for a response to a
> feature request deserves to know that it is not reasonably happening, and
> that there are better ways of trying to get a feature in than opening
> yet-another-feature-request on bugsnet.
>
> I think any bug report opened against 4 and not updated is useless.
>
> I think anything with a patch attached targeting 5 is useless, regardless
> of age; they should be encouraged to open a pull request on github against
> a supported branch.
>
> I'd like to hear what others think about cleaning up bugsnet, what criteria
> we might use for a mass cleanup.
>
> After a mass cleanup, I/we will go in and start working through whatever is
> left, but 5k mostly irrelevant bugs is too much to ask, it would take me
> months and months to work through those, time that nobody has, or will ever
> have.
Thanks for bringing this up, Joe. Generally, I fully agree that we
should clean up the bug tracker ASAP.
I'm not sure, though, if doing a general mass cleanup would really be
the best thing. For instance, there are long-standing feature requests
which should already have been addressed, such as #32803 (I'm going to
start the RFC on this particular one soon) and #31784 (fontconfig is
already supported by external libgd, but not by our bundled one). Also,
there are long-standing bug reports such as #34670 which ideally would
have been resolved in the meantime, but haven't. Just wiping those
under the carpet wouldn't be an improvement, in my opinion.
Instead it would be great if we had active maintainers for all
extensions, and that these maintainers would concentrate on tickets
regarding their respective extensions (including relevant doc bugs).
PECL extensions which are not maintained anymore should be clearly
marked as such (on PECL and in the PHP manual), and all unresolved
issues could be marked as suspended. Unmaintained bundled extensions
should be considererd to be moved to PECL as soon as possible (there is
already a RFC draft[1] about this – I hope this will proceed soon).
Old tickets which can't be easily verified might best be handled by
asking whether the problem persists and setting the issue to "Feeback"
(such as #58167). That would still give users the possibility to
confirm that there's an unresolved problem, what appears to be
preferable to having a new follow-up ticket ("bug #12345 has been
closed, so I'm opening this ticket").
Also, we may consider building a triage team, similar to what had been
proposed for the pull requests[2], but never made it to a discission.
It seems to me that there a quite some developers who could assess a
certain issue, but might not be able to solve it by themselves with a
reasonable amount of effort. Those more proficient with the engine or
the respective extension could concentrate on bugs labeled "verified"
and "analyzed".
[1] <https://wiki.php.net/rfc/umaintained_extensions>
[2] <https://wiki.php.net/rfc/github-pr>
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
