Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] bugsnet cleanup

Posted by Joe Watkins 
Joe Watkins
[PHP-DEV] bugsnet cleanup
January 08, 2017 07:50AM
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
Maciej Sobaczewski
[PHP-DEV] Re: bugsnet cleanup
January 08, 2017 08:20AM
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.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sebastian Bergmann
Re: [PHP-DEV] bugsnet cleanup
January 08, 2017 09:20AM
Am 08.01.2017 um 07:46 schrieb Joe Watkins:
> I think any bug report opened against 4 and not updated is useless.

+1

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

+1


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] bugsnet cleanup
January 08, 2017 11:40AM
On Jan 8, 2017 7:47 AM, "Joe Watkins" <[email protected]> wrote:

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
Joe Watkins
Re: [PHP-DEV] bugsnet cleanup
January 08, 2017 01:50PM
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

On Sun, Jan 8, 2017 at 10:29 AM, Nikita Popov <[email protected]> wrote:

> On Jan 8, 2017 7:47 AM, "Joe Watkins" <[email protected]> wrote:
>
> 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
>
Andreas Heigl
Re: [PHP-DEV] bugsnet cleanup
January 08, 2017 02:00PM
Hi all.

Am 08.01.17 um 11:29 schrieb Nikita Popov:
> On Jan 8, 2017 7:47 AM, "Joe Watkins" <[email protected]> wrote:
>
> 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:[email protected] N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
Attachments:
open | download - smime.p7s (2.4 KB)
Christoph M. Becker
[PHP-DEV] Re: bugsnet cleanup
January 08, 2017 02:10PM
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
Joe Watkins
[PHP-DEV] Re: bugsnet cleanup
January 08, 2017 02:40PM
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 <[email protected]>
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
>
Christoph M. Becker
[PHP-DEV] Re: bugsnet cleanup
January 08, 2017 03:10PM
On 08.01.2017 at 14:31, Joe Watkins wrote:

> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] bugsnet cleanup
January 08, 2017 11:00PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] bugsnet cleanup
January 08, 2017 11:00PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Joe Watkins
Re: [PHP-DEV] bugsnet cleanup
January 09, 2017 07:20AM
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 <[email protected]>
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
>
Kalle Sommer Nielsen
Re: [PHP-DEV] bugsnet cleanup
January 09, 2017 07:50AM
Morning Joe

2017-01-09 7:13 GMT+01:00 Joe Watkins <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Joe Watkins
Re: [PHP-DEV] bugsnet cleanup
January 09, 2017 08:20AM
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

On Mon, Jan 9, 2017 at 6:40 AM, Kalle Sommer Nielsen <[email protected]> wrote:

> Morning Joe
>
> 2017-01-09 7:13 GMT+01:00 Joe Watkins <[email protected]>:
> > 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
>
Remi Collet
Re: [PHP-DEV] bugsnet cleanup
January 09, 2017 08:30AM
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;
Joe Watkins
Re: [PHP-DEV] bugsnet cleanup
January 09, 2017 08:40AM
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

On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet <[email protected]> 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.
>
> 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;
>
>
>
>
Jakub Zelenka
Re: [PHP-DEV] bugsnet cleanup
January 09, 2017 11:10AM
Hi,

On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet <[email protected]> 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.

Cheers

Jakub
Remi Collet
Re: [PHP-DEV] bugsnet cleanup
January 09, 2017 11:10AM
Le 09/01/2017 à 10:59, Jakub Zelenka a écrit :
> Hi,
>
> On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet <[email protected]> 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 ;)
Andreas Heigl
Re: [PHP-DEV] bugsnet cleanup
January 09, 2017 11:20AM
Hi Jakub.

Am 09.01.17 um 10:59 schrieb Jakub Zelenka:
> Hi,
>
> On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet <[email protected]> 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.

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

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:[email protected] N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
Attachments:
open | download - smime.p7s (2.4 KB)
Jakub Zelenka
Re: [PHP-DEV] bugsnet cleanup
January 09, 2017 11:30AM
On Mon, Jan 9, 2017 at 10:04 AM, Remi Collet <[email protected]> wrote:

> Le 09/01/2017 à 10:59, Jakub Zelenka a écrit :
> > Hi,
> >
> > On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet <[email protected]>
> 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".
Jakub Zelenka
Re: [PHP-DEV] bugsnet cleanup
January 09, 2017 12:00PM
On Mon, Jan 9, 2017 at 10:10 AM, Andreas Heigl <[email protected]> wrote:

> Hi Jakub.
>
> Am 09.01.17 um 10:59 schrieb Jakub Zelenka:
> > Hi,
> >
> > On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet <[email protected]>
> 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
Stanislav Malyshev
Re: [PHP-DEV] bugsnet cleanup
January 16, 2017 09:40PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Joe Watkins
Re: [PHP-DEV] bugsnet cleanup
January 17, 2017 09:30AM
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 <[email protected]>
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
>
Marco Pivetta
Re: [PHP-DEV] bugsnet cleanup
January 17, 2017 10:50AM
On Tue, Jan 17, 2017 at 9:19 AM, Joe Watkins <[email protected]> wrote:

> > 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/
Stanislav Malyshev
Re: [PHP-DEV] bugsnet cleanup
January 17, 2017 05:40PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marco Pivetta
Re: [PHP-DEV] bugsnet cleanup
January 17, 2017 05:50PM
On Tue, Jan 17, 2017 at 5:35 PM, Stanislav Malyshev <[email protected]>
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/
Christoph M. Becker
Re: [PHP-DEV] bugsnet cleanup
January 17, 2017 06:00PM
On 17.01.2017 at 17:35, Stanislav Malyshev wrote:

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] bugsnet cleanup
January 17, 2017 06:10PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] bugsnet cleanup
January 17, 2017 06:20PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andreas Heigl
Re: [PHP-DEV] bugsnet cleanup
January 17, 2017 06:30PM
Hi All.

Am 17.01.17 um 17:51 schrieb Christoph M. Becker:
> On 17.01.2017 at 17:35, Stanislav Malyshev wrote:
>
>>> 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

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:[email protected] N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
Attachments:
open | download - smime.p7s (2.4 KB)
Sorry, only registered users may post in this forum.

Click here to login