Morning Christoph,
> Just wiping those under the carpet wouldn't be an improvement, in my
opinion.
Remember that the bugs won't go anywhere, they just won't present
themselves as important to new contributors, and old alike.
It's very overwhelming to see a list of five thousand things that may need
fixing, in reality most of the very old ones don't, and have no chance of
being addressed whatever.
If you're interested in looking through old FR's for stuff to RFC, then you
will still be able to do that.
We also have the option of adding a new status, such as "unresolved", so
that if you're so minded to go and look for old unresolved bugs, you can do
that with a simple search.
Leaving them open isn't helping anyone or anything, and if it overwhelms me
to see that many, you can be pretty sure it has scared a bunch of people
away.
> Instead it would be great if we had active maintainers
Agreed, but we do not, and there isn't much we can do to change that.
The fact is that the burden lies with us to maintain anything in php-src,
not whoever put it there. There are few exceptions, Derick does an
excellent job of maintaining date, there are a few people who work hard to
try to keep PDO and other extensions in shape (or they are emerging now as
maintainers).
> 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).
I'm not sure what you mean by unmaintained, anything bundled is maintained
by virtue of the fact it is bundled ?
There's very few candidates for exclusion today. When I look at the list in
the RFC, it seems pretty obvious why some of them have no maintainer - the
underlying library is frozen in time (readline for example), there isn't
necessarily any real work to do, and nobody is obliged to satisfy
outstanding feature requests.
While I agree that some of those should be removed, I don't think it solves
any long term problems for us.
> Old tickets which can't be easily verified might best be handled by asking
whether the problem persists and setting the issue to "Feedback" (such as
#58167).
This takes the kind of manual labour that we just can't do, and are failing
hard at doing already ... It really would take a team, and we don't have
one.
I know there are a few people that sporadically work on bugs, yourself
included, and that's great.
Maybe you could draft an RFC to put a team together, ask for volunteers to
work on that project and see what happens.
My proposed actions are not about sweeping anything under any carpets, they
are about:
* push people that have opened bugs with patches to go through github,
it's a more effective way of getting the job done
* provide feedback to people that have been waiting for years on end for
some action
* reduce the overall number of bugs so that new and old contributors are
not overwhelmed by the sheer number
* make bugsnet a useful tool for finding things to fix in supported
versions of php - while it may seem that you can just search by version, in
reality this does not work, there are bugs that were opened for some old
version that still apply to 7
At some point, we need to admit that this is not manageable, and that
better tools exist for managing the influx of genuine bugs we do get. I
think actually we should consider closing down bugsnet entirely in the not
too distant future (maybe PHP8) and using the much better collaboration
tools provided by github.
Thanks for your valuable input, I look forward to seeing the bugs triage
RFC.
Cheers
Joe
On Sun, Jan 8, 2017 at 1:00 PM, Christoph M. Becker <cmbecke...@gmx.de>
wrote:
> 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
>
