bugsnet cleanup

7 years ago by Joe Watkins — view source

unread

Morning internals,

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.

Cheers
Joe

7 years ago by Maciej Sobaczewski — view source

unread

Hi Joe,

W dniu 08.01.2017 o 07:46, Joe Watkins pisze:

Morning internals,

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.

Great job on cleaning up Pull Requests. I was really impressed to see
it dropping down from over 300 to about ~140.

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.

Definitely, there was a similiar initiative about 2 years ago IIRC and
I think that cleaning up the bugtracker is always a good thing(tm). I
wasn't able to help with pull requests due to the lack of PHP internal
knowledge, but I would be able to help a little with bug reports.

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.

I would basically close (probably "Suspend", to be more precise) each of
Feature Requests related to the PHP itself. It's not really used anymore
and if I'm right we rather prefer direct mail on php.internals and/or
pull request.

I even thought about disallowing new "Feature Requests" completely and
adding a message that bug tracker is not a suitable place anymore. This,
on the other hand, might be still used for other project types.

I can handle Feature Requests if you're OK with that, I think it should
help a little.

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.

Cheers
Joe

Thanks,
Maciej.

7 years ago by Sebastian Bergmann — view source

unread

Am 08.01.2017 um 07:46 schrieb Joe Watkins:

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.

7 years ago by Nikita Popov — view source

unread

Morning internals,

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 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.

Cheers
Joe

As a general note: By convention the "Closed" state is only for bugs that
have been fixed or feature requests that have been implemented. If
something is not going to be fixed / implemented one of Won't Fix, Not a
Bug or Suspended should be used, as appropriate.

Nikita

7 years ago by Joe Watkins — view source

unread

Afternoon Nikita,

ACK, we should of course use appropriate status ... I have only closed a
few so far before I thought a discussion is probably in order, so no harm
done.

Cheers
Joe

Morning internals,

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.

Cheers
Joe

As a general note: By convention the "Closed" state is only for bugs that
have been fixed or feature requests that have been implemented. If
something is not going to be fixed / implemented one of Won't Fix, Not a
Bug or Suspended should be used, as appropriate.

Nikita

7 years ago by Andreas Heigl — view source

unread

Hi all.

Am 08.01.17 um 11:29 schrieb Nikita Popov:

Morning internals,
[…]

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 even go as far as saying that any bug reported for PHP < 5.6 can be
marked as "Won't fix". The bugs targeting 5.6 need to be checked whether
they have a security implication and if not they should be also marked
as "Won't fix"

There might be issues that are still relevant, but IMHO it's easier to
reopen an issue when need arises than investing the manpower of checking
whether that's still an issue with PHP 7 or not.

Just my 0.02 €

Andreas

PS: Ping me when I shall give a hand at that task!

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+

7 years ago by Stanislav Malyshev — view source

unread

Hi!

I'd even go as far as saying that any bug reported for PHP < 5.6 can be
marked as "Won't fix". The bugs targeting 5.6 need to be checked whether
they have a security implication and if not they should be also marked
as "Won't fix"

Lots of people run 5.5 now. I'd say at least about 2/3 of PHP users in
the field are now < 5.6. Blanket closing all those bugs with "wontfix"
sound non-productive to me - I'd rather at least give people chance to
update the info. Many extension bugs were transferred from 5.x to 7.x as
is.

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Joe Watkins — view source

unread

Morning Stas,

I think we have to separate FRs and bugs. Bugs filed against older
versions (especially ones before 5.5) I'd put into feedback with request
to retest with more recent version. Feedback bugs would automatically
expire if no feedback was provided.

This sounds reasonable.

FRs however need more fine-grained approach. Since they are separate
from bugs, they are easy to filter out and in general may not be
version-specific. OTOH, having them there, indeed, is not super-useful,
but is not that harmful either.

The problem with accepting feature requests on bugsnet is that, most of the
time, nobody can implement them because of modern processes.

It's not harmful to us, but it is harmful to the person requesting the
feature, who is probably ignorant of modern processes, and bound to stay
that way until we educate them, or disable feature requests on bugsnet
altogether.

I think I would like to see feature requests disabled on bugsnet, thereby
pushing everyone to use the proper channels (github, internals, RFC's).

What do you think ?

We can still work through existing requests, but the chances of being able
to act on them are slim, and they are just going to sit there for years on
end.

Cheers
Joe

On Sun, Jan 8, 2017 at 9:57 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

I'd even go as far as saying that any bug reported for PHP < 5.6 can be
marked as "Won't fix". The bugs targeting 5.6 need to be checked whether
they have a security implication and if not they should be also marked
as "Won't fix"

Lots of people run 5.5 now. I'd say at least about 2/3 of PHP users in
the field are now < 5.6. Blanket closing all those bugs with "wontfix"
sound non-productive to me - I'd rather at least give people chance to
update the info. Many extension bugs were transferred from 5.x to 7.x as
is.

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Kalle Sommer Nielsen — view source

unread

Morning Joe

2017-01-09 7:13 GMT+01:00 Joe Watkins pthreads@pthreads.org:

The problem with accepting feature requests on bugsnet is that, most of the
time, nobody can implement them because of modern processes.

It's not harmful to us, but it is harmful to the person requesting the
feature, who is probably ignorant of modern processes, and bound to stay
that way until we educate them, or disable feature requests on bugsnet
altogether.

I think I would like to see feature requests disabled on bugsnet, thereby
pushing everyone to use the proper channels (github, internals, RFC's).

What do you think ?

We can still work through existing requests, but the chances of being able
to act on them are slim, and they are just going to sit there for years on
end.

For Feature Requests, I agree that we should disable them all together
on bugsweb, and add a page for redirecting the user to proper channels
like you mentioned.

Besides this, I would like some more statuses for the bug tracker, or
maybe rather auto reply/quick fixes instead of having to manually
copy/paste over and over again. An example could be:

"This extension ($ext) is no longer being actively maintained (Status:
Suspended)"

Also we got quick fixes for "Try a snapshot (5.4)" and even 5.5!

--
regards,

Kalle Sommer Nielsen
kalle@php.net

7 years ago by Joe Watkins — view source

unread

Morning Kalle,

I would like some more statuses for the bug tracker

+1 go for it

Cleanup of code/statuses is also desirable ... and you have volunteered to
do it :D

Cheers
Joe

Morning Joe

2017-01-09 7:13 GMT+01:00 Joe Watkins pthreads@pthreads.org:

The problem with accepting feature requests on bugsnet is that, most of
the
time, nobody can implement them because of modern processes.

It's not harmful to us, but it is harmful to the person requesting the
feature, who is probably ignorant of modern processes, and bound to stay
that way until we educate them, or disable feature requests on bugsnet
altogether.

I think I would like to see feature requests disabled on bugsnet, thereby
pushing everyone to use the proper channels (github, internals, RFC's).

What do you think ?

We can still work through existing requests, but the chances of being
able
to act on them are slim, and they are just going to sit there for years
on
end.

For Feature Requests, I agree that we should disable them all together
on bugsweb, and add a page for redirecting the user to proper channels
like you mentioned.

Besides this, I would like some more statuses for the bug tracker, or
maybe rather auto reply/quick fixes instead of having to manually
copy/paste over and over again. An example could be:

"This extension ($ext) is no longer being actively maintained (Status:
Suspended)"

Also we got quick fixes for "Try a snapshot (5.4)" and even 5.5!

--
regards,

Kalle Sommer Nielsen
kalle@php.net

7 years ago by Stanislav Malyshev — view source

unread

Hi!

The problem with accepting feature requests on bugsnet is that, most of
the time, nobody can implement them because of modern processes.

Why not? One can attach pull or write an RFC based on it. Having ticket
in bugs.php.net does not prevent it, it just records the need for it.

It's not harmful to us, but it is harmful to the person requesting the
feature, who is probably ignorant of modern processes, and bound to stay
that way until we educate them, or disable feature requests on bugsnet
altogether.

We can add comments to those FRs that require RFCs.

I think I would like to see feature requests disabled on bugsnet,
thereby pushing everyone to use the proper channels (github, internals,
RFC's).

These channels are not exclusive. In fact, bugs site is the only
permanent record for non-RFC requests, and for RFC ones, sometimes
significant time passes between idea showing up and RFC being ready, and
in that time, we won't have any record of anybody needing this.

What do you think ?

I don't think disabling FRs is good. Screening them and noting that some
of them will need RFCs to be implemented is good.

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Joe Watkins — view source

unread

Evening Stas,

(sorry for double delivery to you stas .... grrrrr)

A lot of the time a feature request is just not enough; it requires at
least a good discussion, if not an RFC.

When a PR is made on github, it interrupts everybody's day that has starred
or watched php-src: This has to be many more than have a subscription to,
or bother to read their subscription to bugsnet.

This usually results in a good discussion, at least it will draw out
objections and supporters more effectively than bugsnet does (because you
can just click an emoticon now) .

That there were feature requests open on bugsnet for more than a decade,
some without comments, some open as long as 15 years, should be a hint that
it is not useful as a collaboration tool anymore, and we have at our
disposal some of the best collaboration tools on offer for free.

All I really want to do at the moment is cleanup, but to be perfectly
honest I am not sure why we are using bugsnet for anything, given we took
the effort to switch over to git, source is hosted on github, the vast
majority of PECL extensions are hosted on github (or bitbucket or some
other collab+vcs solution), and they come with far superior collaboration
tools to the ones that nobody bothers to maintain for php-src.

I think this deserves consideration, we should be making the most out of
what is on offer.

I also think that doing things in the wide open has unseen benefits, while
bugsnet is open, it's in a dark corner of the internet that not enough
people bother to visit.

As mentioned, at the moment we should just clean up, but we should look to
the future, and we should move forward also ...

TL;DR I think we can do a better job of this if we use the right tools.

Cheers
Joe

On Mon, Jan 9, 2017 at 10:19 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

The problem with accepting feature requests on bugsnet is that, most of
the time, nobody can implement them because of modern processes.

Why not? One can attach pull or write an RFC based on it. Having ticket
in bugs dot php dot net does not prevent it, it just records the need for
it.

It's not harmful to us, but it is harmful to the person requesting the
feature, who is probably ignorant of modern processes, and bound to stay
that way until we educate them, or disable feature requests on bugsnet
altogether.

We can add comments to those FRs that require RFCs.

I think I would like to see feature requests disabled on bugsnet,
thereby pushing everyone to use the proper channels (github, internals,
RFC's).

These channels are not exclusive. In fact, bugs site is the only
permanent record for non-RFC requests, and for RFC ones, sometimes
significant time passes between idea showing up and RFC being ready, and
in that time, we won't have any record of anybody needing this.

What do you think ?

I don't think disabling FRs is good. Screening them and noting that some
of them will need RFCs to be implemented is good.

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Christoph M. Becker — view source

unread

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

7 years ago by Joe Watkins — view source

unread

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 cmbecker69@gmx.de
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

7 years ago by Christoph M. Becker — view source

unread

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.

I have to agree. Since others already have expressed to be in favor of
a "mass cleanup", I'm not opposed. :-)

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 ?

It appears to me that several extensions get rather "odd fixes" only
(borrowing the terminology of EXTENSIONS).

While I agree that some of those should be removed, I don't think it solves
any long term problems for us.

I beg to differ. Fewer extensions mean less code to maintain.

Maybe you could draft an RFC to put a team together, ask for volunteers to
work on that project and see what happens.

I'll think about it. :-)

--
Christoph M. Becker

7 years ago by Stanislav Malyshev — view source

unread

Hi!

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.

I would like to start with a big thanks to you for doing this. Long
overdue and finally happening!

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 we have to separate FRs and bugs. Bugs filed against older
versions (especially ones before 5.5) I'd put into feedback with request
to retest with more recent version. Feedback bugs would automatically
expire if no feedback was provided.

FRs however need more fine-grained approach. Since they are separate
from bugs, they are easy to filter out and in general may not be
version-specific. OTOH, having them there, indeed, is not super-useful,
but is not that harmful either.

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.

True, some of the FRs actually need an RFC, so maybe we should note as
such on the FRs.

Stas Malyshev
smalyshev@gmail.com

7 years ago by Remi Collet — view source

unread

Hi,

Le 08/01/2017 à 07:46, Joe Watkins a écrit :

I'd like to hear what others think about cleaning up bugsnet, what criteria
we might use for a mass cleanup.

Big +1 for a mass cleanup.

IMHO all bugs reported against PHP < 5.6 could be cleaned.

Perhaps something close to the Fedora bugs process could have some value.

1 month before a version goes EOL: add a comment "you reported this
bug against php xxx which goes EOL on .... It you are able to reproduce
with a newer version please update, else will be closed"
after EOL: close the bugs as "wontfix"

Remi;

7 years ago by Joe Watkins — view source

unread

Morning Remi,

+1 on those criteria and ideas about commenting then closing ...

How long between commenting and closing do you think there should be ?

Kalle is going to get access to the bugsnet box, maybe he could get you
access (if you've time to get directly involved, I super hope you have) ?

Cheers
Joe

Hi,

Le 08/01/2017 à 07:46, Joe Watkins a écrit :

I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.

Big +1 for a mass cleanup.

IMHO all bugs reported against PHP < 5.6 could be cleaned.

Perhaps something close to the Fedora bugs process could have some value.

1 month before a version goes EOL: add a comment "you reported this
bug against php xxx which goes EOL on .... It you are able to reproduce
with a newer version please update, else will be closed"

after EOL: close the bugs as "wontfix"

Remi;

7 years ago by Jakub Zelenka — view source

unread

Hi,

Hi,

Le 08/01/2017 à 07:46, Joe Watkins a écrit :

I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.

Big +1 for a mass cleanup.

IMHO all bugs reported against PHP < 5.6 could be cleaned.

I disagree with this as many of bugs raised before 5.6 are still valid bugs
. The reason is that the code for many extensions hasn't changed for long
time. Of course there was a port to 7.0 which fixed few and also introduce
others but most of the old bugs are still valid. It would just hide
existing issues IMHO.

I think that an ideal way would be to treat each bug individually and at
least try if the issue is still present before closing or ask for feedback
if it's not clear how to try it.

Cheers

Jakub

7 years ago by Remi Collet — view source

unread

Le 09/01/2017 à 10:59, Jakub Zelenka a écrit :

Hi,

Hi,

Le 08/01/2017 à 07:46, Joe Watkins a écrit :

I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.

Big +1 for a mass cleanup.

IMHO all bugs reported against PHP < 5.6 could be cleaned.

I disagree with this as many of bugs raised before 5.6 are still valid bugs
. The reason is that the code for many extensions hasn't changed for long
time. Of course there was a port to 7.0 which fixed few and also introduce
others but most of the old bugs are still valid. It would just hide
existing issues IMHO.

Notice that my proposal includes a "feedback" step ;)

7 years ago by Jakub Zelenka — view source

unread

Le 09/01/2017 à 10:59, Jakub Zelenka a écrit :

Hi,

On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet remi@fedoraproject.org
wrote:

Hi,

Le 08/01/2017 à 07:46, Joe Watkins a écrit :

I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.

Big +1 for a mass cleanup.

IMHO all bugs reported against PHP < 5.6 could be cleaned.

I disagree with this as many of bugs raised before 5.6 are still valid
bugs
. The reason is that the code for many extensions hasn't changed for long
time. Of course there was a port to 7.0 which fixed few and also
introduce
others but most of the old bugs are still valid. It would just hide
existing issues IMHO.

Notice that my proposal includes a "feedback" step ;)

Sure I noticed that. What I wanted to say is not just to automatically
close them if it's possible to try it (e.g. there is a piece of
reproducible code) and there is no feedback. Of course if it's not clear
how to recreate it and there is no feedback, then I agree it should be set
to "Won't fix".

7 years ago by Stanislav Malyshev — view source

unread

Hi!

Sure I noticed that. What I wanted to say is not just to
automatically close them if it's possible to try it (e.g. there is a
piece of reproducible code) and there is no feedback. Of course if
it's not clear how to recreate it and there is no feedback, then I
agree it should be set to "Won't fix".

Won't fix is not a good status for a bug which is not reproducible or
incomplete.
Won't fix means that we know what's going on and we do not intend to
change it. If it's not clear what's going on, we should use status that
expresses it, such as "No feedback".

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Andreas Heigl — view source

unread

Hi Jakub.

Am 09.01.17 um 10:59 schrieb Jakub Zelenka:

Hi,

Hi,

Le 08/01/2017 à 07:46, Joe Watkins a écrit :

I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.

Big +1 for a mass cleanup.

IMHO all bugs reported against PHP < 5.6 could be cleaned.

I disagree with this as many of bugs raised before 5.6 are still valid bugs
. The reason is that the code for many extensions hasn't changed for long
time. Of course there was a port to 7.0 which fixed few and also introduce
others but most of the old bugs are still valid. It would just hide
existing issues IMHO.

I think that an ideal way would be to treat each bug individually and at
least try if the issue is still present before closing or ask for feedback
if it's not clear how to try it.

I can understand that and from what I've seen so far during the cleaning
I can only say that you are right. A lot of the bugs reported for
versions before PHP 5.6 are still open. But going through all the 3000+
issues currently open agains PHP 5 is a LOT of effort. multiply that by
2 to also check whether they are still relevant.

As far as I see it there simply isn't the manpower to do that. We sadly
do not live in an ideal world but in Real Life(TM).

So giving the feedback that the issue was reported against an
unsupported version of PHP and asking the reporter to (re)open the issue
when it still is persistent in a supported version distributes that load
onto more shoulders.

And when it is obvious that the issue is still open, we can easily alter
the PHP-Version within the issue instead of closing it.

For the future an automated mechanism as described earlier would be
awesome. And that would spread the load back onto the reporter as well.

My 0.02€

Cheers

Andreas

7 years ago by Jakub Zelenka — view source

unread

Hi Jakub.

Am 09.01.17 um 10:59 schrieb Jakub Zelenka:

Hi,

On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet remi@fedoraproject.org
wrote:

Hi,

Le 08/01/2017 à 07:46, Joe Watkins a écrit :

I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.

Big +1 for a mass cleanup.

IMHO all bugs reported against PHP < 5.6 could be cleaned.

I disagree with this as many of bugs raised before 5.6 are still valid
bugs
. The reason is that the code for many extensions hasn't changed for long
time. Of course there was a port to 7.0 which fixed few and also
introduce
others but most of the old bugs are still valid. It would just hide
existing issues IMHO.

I think that an ideal way would be to treat each bug individually and at
least try if the issue is still present before closing or ask for
feedback
if it's not clear how to try it.

I can understand that and from what I've seen so far during the cleaning
I can only say that you are right. A lot of the bugs reported for
versions before PHP 5.6 are still open. But going through all the 3000+
issues currently open agains PHP 5 is a LOT of effort. multiply that by
2 to also check whether they are still relevant.

As far as I see it there simply isn't the manpower to do that. We sadly
do not live in an ideal world but in Real Life(TM).

So giving the feedback that the issue was reported against an
unsupported version of PHP and asking the reporter to (re)open the issue
when it still is persistent in a supported version distributes that load
onto more shoulders.

The disadvantage of this is that we can hide many of valid bug reports as
many users won't be just bothered to open it again (especially after 10
years). I don't see a big issues to have bugs open as they actually show
where the issues are and what part needs some work. I actually believe that
it's better to have a bigger backlog so one have got a bigger choice. Of
course cleaning up the bugs that are not really bugs or are already fixed
would be very helpful. However doing that automatically and closing also
the valid ones is not the best way how to do that IMHO.

Cheers

Jakub

7 years ago by Jan Altensen — view source

unread

Am 08.01.2017 um 07:46 schrieb Joe Watkins:

Morning internals,

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.

Cheers
Joe

+1 from me
i would help cleaning up but im not familiar with the bugsnet system :/

7 years ago by Ferenc Kovacs — view source

unread

Morning internals,

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.

Cheers
Joe

hi Joe,

thanks for triaging the github PRs, I also agree that we should do some
culling on our bugsweb issues (relevant: https://www.
joelonsoftware.com/2012/07/09/software-inventory/ ).
just wanted to mention that we have the feedback status, if a bug stays in
the feedback status for 2 weeks the bug will be closed by a cronjob with
the no feedback reason.
we could set the old bugs to feedback with an automatic comment that please
review the issue and target a supported version if you still want this
issue to be resolved and then let the reporters do that or the bug will be
closed.
I think this is a good compromise between just closing/suspending the
issues without explanation.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

7 years ago by Joe Watkins — view source

unread

Morning Ferenc,

That was a good read, and echos my thoughts in places.

I never intended to do anything without explanation, that would obviously
have to be provided.

What I was hoping to extract from this conversation is some criteria for
the updating of bugs: What we actually consider old, what we consider won't
fix, and so on ...

Some good ideas have emerged, and I do hope the bug tracker does get the
attention it deserves in terms of functionality.

People with the power need to do something (that's you :)) to bring the
numbers down and focus our efforts, please do so, starting with updating
old bugs to feedback status.

Cheers
Joe

Morning internals,

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.

Cheers
Joe

hi Joe,

thanks for triaging the github PRs, I also agree that we should do some
culling on our bugsweb issues (relevant: https://www.joelons
oftware.com/2012/07/09/software-inventory/ ).
just wanted to mention that we have the feedback status, if a bug stays
in the feedback status for 2 weeks the bug will be closed by a cronjob with
the no feedback reason.
we could set the old bugs to feedback with an automatic comment that
please review the issue and target a supported version if you still want
this issue to be resolved and then let the reporters do that or the bug
will be closed.
I think this is a good compromise between just closing/suspending the
issues without explanation.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

7 years ago by Stanislav Malyshev — view source

unread

Hi!

A lot of the time a feature request is just not enough; it requires at
least a good discussion, if not an RFC.

True, but some people can not write an RFC, or not ready to do it,
however they still can request and discuss features.

That there were feature requests open on bugsnet for more than a decade,
some without comments, some open as long as 15 years, should be a hint
that it is not useful as a collaboration tool anymore, and we have at
our disposal some of the best collaboration tools on offer for free.

I do not disagree that we need to screen them and sort them, I just
think dropping all of them is going too far. I also disagree that bugs
is not a useful tool, the problem is not the tool but that people are
not using it. If we don't have somebody to go over bugs, no matter what
the tool they will be left behind. If we have somebody, I don't see what
is the problem with bugs.php.net to use it.

All I really want to do at the moment is cleanup, but to be perfectly
honest I am not sure why we are using bugsnet for anything, given we

Why not? It's a working system which we own and we can suit to our needs.

took the effort to switch over to git, source is hosted on github, the

Source is not hosted on github, it's mirrored to github.

vast majority of PECL extensions are hosted on github (or bitbucket or
some other collab+vcs solution), and they come with far superior
collaboration tools to the ones that nobody bothers to maintain for php-src.

Again, the problem is not the tools (which I don't see btw how github is
that superior - if anything it is missing a bunch of features we need
and do have on bugs.php.net) but that almost nobody has been using them.
If people start to use them - and start fixing things that may be
missing too - we can just bugs.php.net just fine.

I think this deserves consideration, we should be making the most out of
what is on offer.

Exactly. Including using existing system we have, not just dropping
everything and moving to github which doesn't have features we need.

I also think that doing things in the wide open has unseen benefits,
while bugsnet is open, it's in a dark corner of the internet that not
enough people bother to visit.

I'm sorry I don't understand this. How bugs.php.net is not open?

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Joe Watkins — view source

unread

Morning Stas :)

True, but some people can not write an RFC, or not ready to do it,
however they still can request and discuss features.

They can do that, but they can also start a discussion on internals if they
want to encourage someone else to do their work for them.

The RFC document already states that things that come without patches are
highly unlikely to happen, things that come without RFC (where they are
required) are even less likely to happen.

I just think dropping all of them is going too far

Well, I'm not really suggesting that, I am looking for criteria to drop
those that are realistically never going to get attention, because they are
not applicable, or for other reasons. But I'm not suggesting we just drop a
bunch because we can't be bothered with them.

I also disagree that bugs
is not a useful tool, the problem is not the tool but that people are
not using it.

Maybe it's not entirely useless, but it's not as useful as other tools we
have at our disposal. As already mentioned, the noise created on github
when pull requests are made is much more effective at generating
conversation than bugs on bugsnet.

We can either spend our time developing tools - note that the last commit
to bugsnet was by Rasmus to fix a "feature" that has never worked, a
feature that we need in order to do a good job, that is still incomplete -
useless is not too strong a word here - or we can spend our time developing
PHP, using tools developed by industry leaders in open source collaboration.

Sure, part of the problem is that people are not using bugsnet, but I do
see github as a partial solution to that - people are using github; you
open issues and pull requests and you make noise, you interrupt everyone's
day that is using github.

Why not? It's a working system which we own and we can suit to our needs.

When things have been broken forever, and when there is no interest in
actually developing these tools, then the observation that we own it, and
that we can mould it to suit are needs are moot - these things are not, as
a matter of fact, relevant, precisely because it does not suit our needs,
and nobody is developing it to meet our needs.

Source is not hosted on github, it's mirrored to github.

Aware :) But to the outsider, that doesn't matter, they can open a pull
request on github as they can for anything else hosted on github.

if anything it is missing a bunch of features we need and do have on
bugs.php.net

The only thing that is legitimately missing is a way to handle security
bugs, as far as I can see ... maybe I'm missing something obvious ?

While we can't assign bugs on github to anyone, we can ping people and get
their attention ... and assigning bugs on bugsnet doesn't seem to be all
that effective anyway. Some bugs have been assigned for years.

Exactly. Including using existing system we have, not just dropping everything
and moving to github which doesn't have features we need.

The existing system we have is somewhere between broken and ineffective, in
my opinion. It's all fine to say that we should develop the tools we need,
but nobody is doing, or has been doing that to an acceptable level. We
have extremely limited resources, if anyone does come along that wants to
work on systems there are far more important things to fix than working on
ancient dilapidated software, things such as our mailing lists, lxr,
jenkins, and really important stuff are more deserving of attention, in my
opinion.

I'm sorry I don't understand this. How bugs.php.net is not open?

I said it is open, but it's not being used, it's not in your face like
github is for a lot of us, it's in a "dark corner of the internet".

Maybe it was too early to suggest we drop it completely, it really doesn't
cover the security issue case, but putting your fingers in your ears and
saying "everything is fine, we just need people to come visit" is not going
to solve the problem that there are several thousand open bugs on bugsnet,
and several thousand active php watchers - would be contributors - on
github, and several miles of nothing in between them.

It would be interesting to compare the analytics of php-src on github, and
the analytics (or traffic) on bugsnet ... I have a feeling that php gets
MUCH more attention on github than it does on bugsnet ... Why not go where
the people are ?

Maybe we can develop ways to use everything more effectively, but with
such limited resources, I don't know why we would ignore industry leading
tools that we already have, in favour of tools that nobody is, or has an
interest in, developing or maintaining to an acceptable level.

Cheers
Joe

On Mon, Jan 16, 2017 at 8:37 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

A lot of the time a feature request is just not enough; it requires at
least a good discussion, if not an RFC.

True, but some people can not write an RFC, or not ready to do it,
however they still can request and discuss features.

That there were feature requests open on bugsnet for more than a decade,
some without comments, some open as long as 15 years, should be a hint
that it is not useful as a collaboration tool anymore, and we have at
our disposal some of the best collaboration tools on offer for free.

I do not disagree that we need to screen them and sort them, I just
think dropping all of them is going too far. I also disagree that bugs
is not a useful tool, the problem is not the tool but that people are
not using it. If we don't have somebody to go over bugs, no matter what
the tool they will be left behind. If we have somebody, I don't see what
is the problem with bugs.php.net to use it.

All I really want to do at the moment is cleanup, but to be perfectly
honest I am not sure why we are using bugsnet for anything, given we

Why not? It's a working system which we own and we can suit to our needs.

took the effort to switch over to git, source is hosted on github, the

Source is not hosted on github, it's mirrored to github.

vast majority of PECL extensions are hosted on github (or bitbucket or
some other collab+vcs solution), and they come with far superior
collaboration tools to the ones that nobody bothers to maintain for
php-src.

Again, the problem is not the tools (which I don't see btw how github is
that superior - if anything it is missing a bunch of features we need
and do have on bugs.php.net) but that almost nobody has been using them.
If people start to use them - and start fixing things that may be
missing too - we can just bugs.php.net just fine.

I think this deserves consideration, we should be making the most out of
what is on offer.

Exactly. Including using existing system we have, not just dropping
everything and moving to github which doesn't have features we need.

I also think that doing things in the wide open has unseen benefits,
while bugsnet is open, it's in a dark corner of the internet that not
enough people bother to visit.

I'm sorry I don't understand this. How bugs.php.net is not open?

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Marco Pivetta — view source

unread

I'm sorry I don't understand this. How bugs.php.net is not open?

I said it is open, but it's not being used, it's not in your face like
github is for a lot of us, it's in a "dark corner of the internet".

We (doctrine project, in this context) moved all our issues from our own
"open" Jira to Github last year, and activity started buzzing.

People can now cross-reference issues, discuss, get notifications, and have
some simplified/readable markup.
For the 99% of developers, this is better than any self-hosted tool with
its own workflow, and also more familiar (we all use Github, unless we live
under a rock, which is the 1%).

We really disliked the move, because Jira had integrated workflows as we
wanted them, as well as security issues (discussed above) and
multi-milestone support, but I'd trust a GPG encrypted mail over Jira's
MySQL instance for storing those security issues.

Still, activity buzzed after the move.
Yes, it is chaotic, but at least people can help out, cross-link, and
generally be more part of the workflow.

As it currently stands, I only go to bugs.php.net to create a github issue
where I link it as reference.

Just my 2 cents.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

7 years ago by Stanislav Malyshev — view source

unread

Hi!

People can now cross-reference issues, discuss, get notifications, and
have some simplified/readable markup.

All this, except for markup, is available on bugs.php.net. And I don't
think markup is that important - I'm pretty sure one can discuss bugs in
plain text.

For the 99% of developers, this is better than any self-hosted tool with
its own workflow, and also more familiar (we all use Github, unless we
live under a rock, which is the 1%).

There's a lot of use of github as code distribution/review tool, true.
Github as a project management/bug tracking tool is much less widely
used, and for a reason - it lacks a lot of capabilities such tools
should have. It is a very mediocre bug tracking/project management tool,
and that's charitable. It's not their fault - github never was targeted
at this and their issue tracking capabilities clearly target smaller and
simpler projects with less advanced needs. But I don't think it would
work well for a bigger one.
Trading superior solution for a clearly inferior one because "all cool
boys do it" does not look like something we should do.

Still, activity buzzed after the move.
Yes, it is chaotic, but at least people can help out, cross-link, and
generally be more part of the workflow.

Again, people can do all this on bugs.php.net. If there are real problem
with it, we should fix it. If the problem is "oh, I need to type
different URL, that's too much for me!" - maybe it's not the kind of
buzzing we want to get.

As it currently stands, I only go to bugs.php.net http://bugs.php.net
to create a github issue where I link it as reference.

What prevents you from being able to create proper issues on bugs.php.net?

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Marco Pivetta — view source

unread

On Tue, Jan 17, 2017 at 5:35 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:

What prevents you from being able to create proper issues on bugs.php.net?

Nothing: it's just a forgotten corner of the web, like our Jira was.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

7 years ago by Stanislav Malyshev — view source

unread

Hi!

Nothing: it's just a forgotten corner of the web, like our Jira was.

I'm sorry, I don't get this "forgotten corner" thing. What exactly is
missing there - glitter? Celebrity endorsements? We have a fully
functional tool, easy to use and available to anybody that needs it. We
do not have to fill ads quota or fulfill traffic targets.
Now you claim it's "forgotten" because you do not use it, and you do not
use it because it's "forgotten". Sorry, I don't get it. Is there any
real problem with it?

Stas Malyshev
smalyshev@gmail.com

7 years ago by David Lundgren — view source

unread

On Tue, Jan 17, 2017 at 5:35 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:

What prevents you from being able to create proper issues on bugs.php.net?

Nothing: it's just a forgotten corner of the web, like our Jira was.

Why not put a link to bugs.php.net in the github php-src repository
description or web-site fields? I've seen other projects with multiple
websites listed.

"The PHP Interpreter http://www.php.net Please submit issues at
http://bugs.php.net";

or something along those lines. Perhaps this can help to make the
tracker a little more visible?

Dave

David Lundgren
dlundgren@syberisle.net
GPG: 0x26F54D7F

7 years ago by Christoph M. Becker — view source

unread

People can now cross-reference issues, discuss, get notifications, and
have some simplified/readable markup.

All this, except for markup, is available on bugs.php.net. And I don't
think markup is that important - I'm pretty sure one can discuss bugs in
plain text.

Well, what is missing is a simple means to ping another developer –
currently the only way to do so is assigning the ticket to them, but
that's not always appropriate.

--
Christoph M. Becker

7 years ago by Stanislav Malyshev — view source

unread

Hi!

Well, what is missing is a simple means to ping another developer –
currently the only way to do so is assigning the ticket to them, but
that's not always appropriate.

True. Should not be hard to implement though I think.

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Andreas Heigl — view source

unread

Hi All.

Am 17.01.17 um 17:51 schrieb Christoph M. Becker:

People can now cross-reference issues, discuss, get notifications, and
have some simplified/readable markup.

All this, except for markup, is available on bugs.php.net. And I don't
think markup is that important - I'm pretty sure one can discuss bugs in
plain text.

Well, what is missing is a simple means to ping another developer –
currently the only way to do so is assigning the ticket to them, but
that's not always appropriate.

Personally I think it's best for a project like the PHP-Project to stay
as independent as possible. And that also means have our own bugtracker.
And as the whole project is about a programming language why the heck
should that bugtracker not be written in (vanilla) PHP.

That gives us the advantage that we can decide what we need and have the
possibility to change it according to changing needs.

But that also has the disadvantage that we have to decide what we need
and that we have to change it according to changing needs. And that is
where I currently see an issue.

Searching Bugs is - lets put it diplomatic - a challenge. The
fulltext-search doesn't work pretty well, the list of possible
subprojects is endless and the pull request I submitted to be able to
search for commenters names is still sitting in the PR queue for the
last 16 months or so.

Which brings me to the next thing: It isn't clear who's in charge.
Issues with the bug-tracker are handled in a similar timely manner as
some issues in the language itself. So why should one invest time to
adapt the bugtracker to our needs when no one seems to notice or care.

So no wonder people are looking for alternatives. And let's be honest
here: The UI looks pretty – 2001? A facelift would make a difference:
But who would do it? And when someone would do it: Who'd actually apply it?

For me the Bugtracker works pretty OK. There are things that could be
handled better but for managing issues, assigning them etc it's OK.
Definitely not worse than Github-issues!

We should work on making transparent who's in charge for the
issue-tracker and whom to address for issues with it. Only then it's
possible to bring people back to it and add fixes to their own itches.

Like adding a PR to notify people by mentioning them. Or by allowing
code-samples to be formatted. Because formatted code is easier to read
than unformatted code. And we already make formatting in plain text, so
why not allow that in the bug-tracker?

And because there are a lot of "should"s and "could"s in there: I'd love
to help out: But someone will need to help me (or whoever else wants to
help) in getting to know the details and internals of – internals? – the
system…

Just my 0.02 €

Cheers

Andreas

7 years ago by Niklas Keller — view source

unread

2017-01-17 18:22 GMT+01:00 Andreas Heigl andreas@heigl.org:

Hi All.

Am 17.01.17 um 17:51 schrieb Christoph M. Becker:

People can now cross-reference issues, discuss, get notifications, and
have some simplified/readable markup.

All this, except for markup, is available on bugs.php.net. And I don't
think markup is that important - I'm pretty sure one can discuss bugs in
plain text.

Well, what is missing is a simple means to ping another developer –
currently the only way to do so is assigning the ticket to them, but
that's not always appropriate.

Personally I think it's best for a project like the PHP-Project to stay
as independent as possible. And that also means have our own bugtracker.
And as the whole project is about a programming language why the heck
should that bugtracker not be written in (vanilla) PHP.

That gives us the advantage that we can decide what we need and have the
possibility to change it according to changing needs.

But that also has the disadvantage that we have to decide what we need
and that we have to change it according to changing needs. And that is
where I currently see an issue.

Searching Bugs is - lets put it diplomatic - a challenge. The
fulltext-search doesn't work pretty well, the list of possible
subprojects is endless and the pull request I submitted to be able to
search for commenters names is still sitting in the PR queue for the
last 16 months or so.

Which brings me to the next thing: It isn't clear who's in charge.
Issues with the bug-tracker are handled in a similar timely manner as
some issues in the language itself. So why should one invest time to
adapt the bugtracker to our needs when no one seems to notice or care.

So no wonder people are looking for alternatives. And let's be honest
here: The UI looks pretty – 2001? A facelift would make a difference:
But who would do it? And when someone would do it: Who'd actually apply it?

For me the Bugtracker works pretty OK. There are things that could be
handled better but for managing issues, assigning them etc it's OK.
Definitely not worse than Github-issues!

We should work on making transparent who's in charge for the
issue-tracker and whom to address for issues with it. Only then it's
possible to bring people back to it and add fixes to their own itches.

Like adding a PR to notify people by mentioning them. Or by allowing
code-samples to be formatted. Because formatted code is easier to read
than unformatted code. And we already make formatting in plain text, so
why not allow that in the bug-tracker?

And because there are a lot of "should"s and "could"s in there: I'd love
to help out: But someone will need to help me (or whoever else wants to
help) in getting to know the details and internals of – internals? – the
system…

Just my 0.02 €

Cheers

Andreas

That's exactly the issue PHP currently has, no clear responsibilities. The
mailing system is one nobody understands, the bug tracker is something
nobody cares to maintain. I can completely understand people saying PHP
should stay as independent as possible, but that only works as long as
there's one if not many to maintain our own systems.

I could help improving the bug tracker, but it's only worth if those
updates will get deployed. I even tried to get it working locally some time
ago, but had issues setting it up, I think they were related to PEAR.

Regards, Niklas

7 years ago by Maciej Sobaczewski — view source

unread

W dniu 17.01.2017 o 18:47, Niklas Keller pisze:

2017-01-17 18:22 GMT+01:00 Andreas Heigl andreas@heigl.org:

Hi All.

Am 17.01.17 um 17:51 schrieb Christoph M. Becker:

People can now cross-reference issues, discuss, get notifications, and
have some simplified/readable markup.

All this, except for markup, is available on bugs.php.net. And I don't
think markup is that important - I'm pretty sure one can discuss bugs in
plain text.

Well, what is missing is a simple means to ping another developer –
currently the only way to do so is assigning the ticket to them, but
that's not always appropriate.

Personally I think it's best for a project like the PHP-Project to stay
as independent as possible. And that also means have our own bugtracker.
And as the whole project is about a programming language why the heck
should that bugtracker not be written in (vanilla) PHP.

That gives us the advantage that we can decide what we need and have the
possibility to change it according to changing needs.

But that also has the disadvantage that we have to decide what we need
and that we have to change it according to changing needs. And that is
where I currently see an issue.

Searching Bugs is - lets put it diplomatic - a challenge. The
fulltext-search doesn't work pretty well, the list of possible
subprojects is endless and the pull request I submitted to be able to
search for commenters names is still sitting in the PR queue for the
last 16 months or so.

Which brings me to the next thing: It isn't clear who's in charge.
Issues with the bug-tracker are handled in a similar timely manner as
some issues in the language itself. So why should one invest time to
adapt the bugtracker to our needs when no one seems to notice or care.

So no wonder people are looking for alternatives. And let's be honest
here: The UI looks pretty – 2001? A facelift would make a difference:
But who would do it? And when someone would do it: Who'd actually apply it?

For me the Bugtracker works pretty OK. There are things that could be
handled better but for managing issues, assigning them etc it's OK.
Definitely not worse than Github-issues!

We should work on making transparent who's in charge for the
issue-tracker and whom to address for issues with it. Only then it's
possible to bring people back to it and add fixes to their own itches.

Like adding a PR to notify people by mentioning them. Or by allowing
code-samples to be formatted. Because formatted code is easier to read
than unformatted code. And we already make formatting in plain text, so
why not allow that in the bug-tracker?

And because there are a lot of "should"s and "could"s in there: I'd love
to help out: But someone will need to help me (or whoever else wants to
help) in getting to know the details and internals of – internals? – the
system…

Just my 0.02 €

Cheers

Andreas

That's exactly the issue PHP currently has, no clear responsibilities. The
mailing system is one nobody understands, the bug tracker is something
nobody cares to maintain. I can completely understand people saying PHP
should stay as independent as possible, but that only works as long as
there's one if not many to maintain our own systems.

I could help improving the bug tracker, but it's only worth if those
updates will get deployed. I even tried to get it working locally some time
ago, but had issues setting it up, I think they were related to PEAR.

Regards, Niklas

Hi,

since the discussion went a bit off-topic and many of us would like to
see some improvements for the bugtracker itself, could we please
continue this topic separately? I created new thread on php.webmster
mailinglist and created https://wiki.php.net/ideas/bugtracker

Feel free to give your ideas. It always starts with an idea.

Thanks,
Maciej.

True, some of the FRs actually need an RFC, so maybe we should note as such on the FRs.

Dave

True, some of the FRs actually need an RFC, so maybe we should note as
such on the FRs.