Re: [PHP-DEV] Bugsnet

[Jakub Zelenka]

On Thu, 21 Oct 2021, 22:46 Nikita Popov,  wrote:

> On Thu, Oct 21, 2021 at 10:42 PM Jakub Zelenka  wrote:
>
>> On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov 
>> wrote:
>>
>>>
>>> I'm proposing the following label structure (the list at
>>> https://github.com/nikic/test-repo/labels is incomplete though): Each
>>> report has either a bug or feature label. Additionally it starts out with
>>> the T-needs-triage label. Once a project member triages the report, the
>>> label is removed and a category label is added instead, e.g. C-OpenSSL
>>> for
>>> issues relating to the OpenSSL extension.
>>>
>>> I also have a few more triage labels (T-needs-feedback, T-verified,
>>> T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
>>> but the first one or the first two -- I personally don't see a lot of
>>> value
>>> in having a label for why exactly an issue has been closed, the fact that
>>> it is closed is usually sufficient.
>>>
>>>
>> Have you considered custom fields that are now in beta with some other
>> features in https://github.com/features/issues ? That seems a bit nicer
>> to me...
>>
>
> Yes, I tested this as well (the PHP organization is signed up for the
> beta). Unfortunately, I found this functionality rather awkward and don't
> think it would work well for us. The key problem is that the new
> functionality is not an improvement for issues -- it's an improvement for
> "projects". You can add an issue to a project (manually) and then you can
> add extra metadata to the issue in that project. It's not possible to add
> custom fields to issues themselves.
>
>
Ah ok. That's a bit useless then. :) I agree that it wouldn't probably work
well for us though.

+1 on your proposal. I think that makes sense and could work well.

Regards

Jakub

Re: [PHP-DEV] Bugsnet

[Nikita Popov]

On Thu, Oct 21, 2021 at 10:42 PM Jakub Zelenka  wrote:

> On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov  wrote:
>
>>
>> I'm proposing the following label structure (the list at
>> https://github.com/nikic/test-repo/labels is incomplete though): Each
>> report has either a bug or feature label. Additionally it starts out with
>> the T-needs-triage label. Once a project member triages the report, the
>> label is removed and a category label is added instead, e.g. C-OpenSSL for
>> issues relating to the OpenSSL extension.
>>
>> I also have a few more triage labels (T-needs-feedback, T-verified,
>> T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
>> but the first one or the first two -- I personally don't see a lot of
>> value
>> in having a label for why exactly an issue has been closed, the fact that
>> it is closed is usually sufficient.
>>
>>
> Have you considered custom fields that are now in beta with some other
> features in https://github.com/features/issues ? That seems a bit nicer
> to me...
>

Yes, I tested this as well (the PHP organization is signed up for the
beta). Unfortunately, I found this functionality rather awkward and don't
think it would work well for us. The key problem is that the new
functionality is not an improvement for issues -- it's an improvement for
"projects". You can add an issue to a project (manually) and then you can
add extra metadata to the issue in that project. It's not possible to add
custom fields to issues themselves.

Regards,
Nikita

Re: [PHP-DEV] Bugsnet

[Jakub Zelenka]

On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov  wrote:

>
> I'm proposing the following label structure (the list at
> https://github.com/nikic/test-repo/labels is incomplete though): Each
> report has either a bug or feature label. Additionally it starts out with
> the T-needs-triage label. Once a project member triages the report, the
> label is removed and a category label is added instead, e.g. C-OpenSSL for
> issues relating to the OpenSSL extension.
>
> I also have a few more triage labels (T-needs-feedback, T-verified,
> T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
> but the first one or the first two -- I personally don't see a lot of value
> in having a label for why exactly an issue has been closed, the fact that
> it is closed is usually sufficient.
>
>
Have you considered custom fields that are now in beta with some other
features in https://github.com/features/issues ? That seems a bit nicer to
me...

Regards

Jakub

Re: [PHP-DEV] Bugsnet

[Nikita Popov]

On Sun, May 9, 2021 at 8:49 AM Joe Watkins  wrote:

> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>
> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>
> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>
> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on
> github.
>
> I think we might get quite a good response here - anyone suffering the
> worst consequences of bugs - production servers can't be upgraded and so on
> - are already waiting for a notification from bugsnet, I'm sure the
> majority of them will do as we ask.
>
> In some set number of weeks (to be decided), and depending on the response
> to our switching over to github, we can try to determine at that time if
> it's worth trying to import any data from bugsnet. We can also consider at
> this time when it might be appropriate to retire bugsnet entirely.
>
> We will not be free of spam simply by moving, but github has the tools we
> need to moderate the content properly - you can block people. In addition,
> I feel people are less likely to misbehave if they think their co-workers
> or employers might be able to see what they are doing, which may have an
> effect also.
>
> It may be over optimistic, but we might get better engagement with bugs on
> github than anywhere else also - Github is where people are tending to do
> their business today.
>
> Github is maintained, hosted, developed, and free, and while it isn't the
> perfect tool for the job, nothing else is either. We could spend time
> (which we don't have) developing bugsnet, or installing some other solution
> in a dark corner of the internet, and solve no problems at all, and be
> burdened with the ongoing maintenance of that solution.
>
> The people who have to spend the most time on this are release managers,
> and so while I'm talking to everyone, it is release managers opinions that
> I'm most interested in, they are the people who will be and have been most
> effected by the shortcomings in bugsnet, whose opinions are most relevant
> in this space.
>
> I don't think a vote is appropriate, this decision should be made by the
> people whose "jobs" are directly effected - with input from the community,
> of course. Not least of all, it will take a month to close a vote, by which
> time we will have wasted another (working) day or more of Nikitas time.
> Having said all that, I am looking for a consensus before we take any
> action. My arm can be twisted, but this is my current position and I think
> it's a reasonable one.
>
> On the issue of responsible disclosure ... we can treat this separately,
> with the recent change in the workflow, this process is in need of review
> anyway. How that is handled should be decided by the people who have a hand
> in that process, and so it seems prudent to leave it aside for now.
>
> Cheers
> Joe
>

To follow up on this proposal: We have been using GitHub Issue for docs for
a while now (https://github.com/php/doc-en/issues) and I'm about to disable
submission of new docs issues on bugs.php.net. I think it's time to switch
non-security bugs for PHP proper as well, for all the reasons that have
already been discussed.

For docs we didn't really do anything special in terms of labels etc. I
think for the php-src repo we do want to introduce some more structure for
categorization and triage, as the volume tends to be higher there.

For that purpose I've created a prototype of how things could look like
here: 

Re: [PHP-DEV] Bugsnet

[Christoph M. Becker]

On 10.05.2021 at 15:39, Andreas Heigl wrote:
> Hey All
>
> Am 10.05.21 um 14:44 schrieb Alexander Kurilo via internals:
>> On 09/05/2021 09:48, Joe Watkins wrote:
>>> Morning internals,
>>>
>>> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
>>> waste time deleting 20 odd messages from bugsnet yesterday and this is a
>>> common, daily occurrence. We clearly don't have time for this.
>>>
>>> Quite aside from spam problems, bugsnet is hidden away in a dark
>>> corner of
>>> the internet that requires a special login, doesn't integrate with source
>>> code or our current workflow (very nicely), and doesn't get updated or
>>> developed.
>>
>>
>> So, there are 2 distinct issues: spam from bugsnet (this one can be
>> mitigated by replacing current "solve a problem" challenge by something
>> more sophisticated) and the bugsnet itself being a burden (which can't
>> be solved quickly).
>>
>> Let's separate the two: this way we can have kill the spam in the short
>> term and get enough time to shape out the migration plan if there's a
>> consensus on the matter.
>>
>> What about integrating [recaptcha][1] for now? Integration is rather
>> simple but there are other concerns, e.g. a third-party JS code on the
>> page that accepts security issues.
>
> If so, can we please use something else? Implementing a Honeypot or a
> simple math-captcha isn't that complicated (and I assume that a person
> that can provide a decent bug description can also solve a riddle like
> "Enter the result of 7 plus 2")

We already have a simple math CAPTCHA; it doesn't work, though, if users
switch browser tabs.  Anyhow, I don't think that a CAPTCHA would be
really helpful; we need some real user authentication; this way we could
also block unwanted users.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet

[Remi Collet]

Le 09/05/2021 à 08:48, Joe Watkins a écrit :


Having moved our workflow to github, now seems to be the time to seriously
consider retiring bugsnet for general use, and using the tools that are
waiting for us - Github Issues.


Please NO

This mean we will drop ownership on all data and history about bug.



Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet

[Andreas Heigl]

Hey All

Am 10.05.21 um 14:44 schrieb Alexander Kurilo via internals:
> On 09/05/2021 09:48, Joe Watkins wrote:
>> Morning internals,
>>
>> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
>> waste time deleting 20 odd messages from bugsnet yesterday and this is a
>> common, daily occurrence. We clearly don't have time for this.
>>
>> Quite aside from spam problems, bugsnet is hidden away in a dark
>> corner of
>> the internet that requires a special login, doesn't integrate with source
>> code or our current workflow (very nicely), and doesn't get updated or
>> developed.
> 
> 
> So, there are 2 distinct issues: spam from bugsnet (this one can be
> mitigated by replacing current "solve a problem" challenge by something
> more sophisticated) and the bugsnet itself being a burden (which can't
> be solved quickly).
> 
> Let's separate the two: this way we can have kill the spam in the short
> term and get enough time to shape out the migration plan if there's a
> consensus on the matter.
> 
> What about integrating [recaptcha][1] for now? Integration is rather
> simple but there are other concerns, e.g. a third-party JS code on the
> page that accepts security issues.

If so, can we please use something else? Implementing a Honeypot or a
simple math-captcha isn't that complicated (and I assume that a person
that can provide a decent bug description can also solve a riddle like
"Enter the result of 7 plus 2")

Thanks!

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] Bugsnet

[Alexander Kurilo via internals]

On 09/05/2021 09:48, Joe Watkins wrote:

Morning internals,

We have a spam problem on bugsnet, it's not a new problem. Nikita had to
waste time deleting 20 odd messages from bugsnet yesterday and this is a
common, daily occurrence. We clearly don't have time for this.

Quite aside from spam problems, bugsnet is hidden away in a dark corner of
the internet that requires a special login, doesn't integrate with source
code or our current workflow (very nicely), and doesn't get updated or
developed.



So, there are 2 distinct issues: spam from bugsnet (this one can be 
mitigated by replacing current "solve a problem" challenge by something 
more sophisticated) and the bugsnet itself being a burden (which can't 
be solved quickly).


Let's separate the two: this way we can have kill the spam in the short 
term and get enough time to shape out the migration plan if there's a 
consensus on the matter.


What about integrating [recaptcha][1] for now? Integration is rather 
simple but there are other concerns, e.g. a third-party JS code on the 
page that accepts security issues.


If it sounds like a way to go, I can help with the integration. Thanks 
to [Dan Ackroyd's pull request][2], setting up environment for torturing 
bugsnet locally is a no-brainer.


[1]: https://www.google.com/recaptcha/about/
[2]: https://github.com/php/web-bugs/pull/91

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet

[Benjamin Eberlei]

On Sun, May 9, 2021 at 8:49 AM Joe Watkins  wrote:

> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>
> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>
> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>
> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on
> github.
>
> I think we might get quite a good response here - anyone suffering the
> worst consequences of bugs - production servers can't be upgraded and so on
> - are already waiting for a notification from bugsnet, I'm sure the
> majority of them will do as we ask.
>
> In some set number of weeks (to be decided), and depending on the response
> to our switching over to github, we can try to determine at that time if
> it's worth trying to import any data from bugsnet. We can also consider at
> this time when it might be appropriate to retire bugsnet entirely.
>
> We will not be free of spam simply by moving, but github has the tools we
> need to moderate the content properly - you can block people. In addition,
> I feel people are less likely to misbehave if they think their co-workers
> or employers might be able to see what they are doing, which may have an
> effect also.
>
> It may be over optimistic, but we might get better engagement with bugs on
> github than anywhere else also - Github is where people are tending to do
> their business today.
>

One downside of this "easy access" is that Github Issues tend to get used
as support question forum, at least from my experience on Doctrine it can
easily be 50% of the issues that are support questions. This is much more
work to process than simple spam issues, because there is a human on the
other side who need to be directed towards the proper support channel.

In addition I agree with Rowans assessment that large projects usually have
lots of automation in place on top of Github issues that we would again
need to configure, write or maintain in one way or another.

bugsweb on the other hand is a "classic LAMP" stack application, so maybe
we could look into removing the infrastructure variable from the hosting
equation and look for a PaaS provider? Spam protection third party services
are also available and might potentially be integrated with in a reasonable
amount of time.


> Github is maintained, hosted, developed, and free, and while it isn't the
> perfect tool for the job, nothing else is either. We could spend time
> (which we don't have) developing bugsnet, or installing some other solution
> in a dark corner of the internet, and solve no problems at all, and be
> burdened with the ongoing maintenance of that solution.
>
> The people who have to spend the most time on this are release managers,
> and so while I'm talking to everyone, it is release managers opinions that
> I'm most interested in, they are the people who will be and have been most
> effected by the shortcomings in bugsnet, whose opinions are most relevant
> in this space.
>
> I don't think a vote is appropriate, this decision should be made by the
> people whose "jobs" are directly effected - with input from the community,
> of course. Not least of all, it will take a month to close a vote, by which
> time we will have wasted another (working) day or more of Nikitas time.
> Having said all that, I am looking for a consensus before we take any
> action. My arm can be twisted, but this is my current position and I think
> it's a reasonable one.
>
> On the issue of responsible disclosure ... we can treat this separately,
> with the 

Re: [PHP-DEV] Bugsnet

[Mike Schinkel]

> On May 9, 2021, at 4:58 AM, Rowan Tommins  wrote:
> 
> On 9 May 2021 08:33:08 BST, Stanislav Malyshev  wrote:
>> It is not good that our infrastructure is "hidden away in a dark 
>> corner", and it is true that bugs needs some TLC for a while. But
>> Github 
>> Issues frankly sucks big time as a bug management system. It's hard to 
>> fault them as it's not their core business - but while it may be 
>> adequate for a small project, I don't see how Github system could be 
>> manageable with any serious volume. 
> 
> 
> This is my instinct as well - Github Issues seems to be adequate as a 
> lightweight bug tracker, but how well will it scale, and how much will we 
> miss "advanced" features like separately searchable and reportable fields and 
> statuses? Are we better off looking for a SaaS that can provide something 
> more full-featured - Mantis, Phabricator, Trac, Bugzilla, YouTrack, etc?

Possibly the best of both worlds:

https://github.com/marketplace/zube 
https://github.com/marketplace/skope-github-issue-tracker 

https://github.com/marketplace/orwell-app 

https://github.com/marketplace/codetree 


Plus another 545 PM-related apps and actions to fill in those "advanced" 
features that are missing from the Github tracker:

https://github.com/marketplace/category/project-management 


And this list should only get better over time.  

And for any functionality missing, there are always these:

https://github.com/KnpLabs/php-github-api 

https://github.com/googleapis/google-api-php-client 

https://github.com/mpscholten/github-api 

https://github.com/googleapis/google-api-php-client-services 



Rhetorical question: What developer today does not have experience with Github 
issues?  Not so for many (any?) others.

Github issues FTW!  IMO, anyway. :-)

-Mike 

Re: [PHP-DEV] Bugsnet

[Levi Morrison]

On Sun, May 9, 2021 at 8:26 AM Larry Garfield  wrote:
>
> On Sun, May 9, 2021, at 1:48 AM, Joe Watkins wrote:
> > Morning internals,
> >
> > We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> > waste time deleting 20 odd messages from bugsnet yesterday and this is a
> > common, daily occurrence. We clearly don't have time for this.
> >
> > Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> > the internet that requires a special login, doesn't integrate with source
> > code or our current workflow (very nicely), and doesn't get updated or
> > developed.
> >
> > Having moved our workflow to github, now seems to be the time to seriously
> > consider retiring bugsnet for general use, and using the tools that are
> > waiting for us - Github Issues.
> >
> > I'm aware that bugsnet serves as the disclosure method for security bugs
> > and github doesn't have a solution to that. Leaving that to one side for
> > now ...
> >
> > I'm also aware that bugsnet carries with it 20 years worth of crusty old
> > feature requests and bugs, that are never realistically going to be dealt
> > with. In the past I've spent time trying to close very old bugs that no
> > longer seem relevant, the fact is that there are so many of these that I
> > don't think I made a dent.
> >
> > It seems obvious that we don't want to migrate all of the data on bugsnet,
> > but nor do we want to loose the most recent and relevant reports.
> >
> > I propose that we disable bugsnet for all but security issues leaving
> > responsible disclosure method to be handled in some other way at a later
> > date. Leaving bugsnet in a (mostly) readonly mode.
> >
> > We then send a notification to all bugs that were opened against a specific
> > and supported version of PHP, notifying the opener of the change and
> > requesting that they take a couple of minutes to open their issue on github.
> >
> > I think we might get quite a good response here - anyone suffering the
> > worst consequences of bugs - production servers can't be upgraded and so on
> > - are already waiting for a notification from bugsnet, I'm sure the
> > majority of them will do as we ask.
> >
> > In some set number of weeks (to be decided), and depending on the response
> > to our switching over to github, we can try to determine at that time if
> > it's worth trying to import any data from bugsnet. We can also consider at
> > this time when it might be appropriate to retire bugsnet entirely.
> >
> > We will not be free of spam simply by moving, but github has the tools we
> > need to moderate the content properly - you can block people. In addition,
> > I feel people are less likely to misbehave if they think their co-workers
> > or employers might be able to see what they are doing, which may have an
> > effect also.
> >
> > It may be over optimistic, but we might get better engagement with bugs on
> > github than anywhere else also - Github is where people are tending to do
> > their business today.
> >
> > Github is maintained, hosted, developed, and free, and while it isn't the
> > perfect tool for the job, nothing else is either. We could spend time
> > (which we don't have) developing bugsnet, or installing some other solution
> > in a dark corner of the internet, and solve no problems at all, and be
> > burdened with the ongoing maintenance of that solution.
> >
> > The people who have to spend the most time on this are release managers,
> > and so while I'm talking to everyone, it is release managers opinions that
> > I'm most interested in, they are the people who will be and have been most
> > effected by the shortcomings in bugsnet, whose opinions are most relevant
> > in this space.
> >
> > I don't think a vote is appropriate, this decision should be made by the
> > people whose "jobs" are directly effected - with input from the community,
> > of course. Not least of all, it will take a month to close a vote, by which
> > time we will have wasted another (working) day or more of Nikitas time.
> > Having said all that, I am looking for a consensus before we take any
> > action. My arm can be twisted, but this is my current position and I think
> > it's a reasonable one.
> >
> > On the issue of responsible disclosure ... we can treat this separately,
> > with the recent change in the workflow, this process is in need of review
> > anyway. How that is handled should be decided by the people who have a hand
> > in that process, and so it seems prudent to leave it aside for now.
> >
> > Cheers
> > Joe
>
> I agree with Joe that this is a decision that should be made mainly by the 
> release managers, very-high-level contributors (Nikita, Dmitry, etc.), and 
> whatever passes for sysadmins around here. :-)  As a fan of decoupling, 
> however, I want to note that it sounds like there's a couple of separate 
> issues involved here, for which GitHub is one possible solution.
>
> Problem: The current system has a spam problem.
> GitHub 

Re: [PHP-DEV] Bugsnet

[Wim Godden]

On 9/05/2021 8:48, Joe Watkins wrote:

I'm aware that bugsnet serves as the disclosure method for security bugs
and github doesn't have a solution to that. Leaving that to one side for
now ...
Just want to weigh in on this item (also mentioned by Stanislav as an 
important issue). Although Github doesn't provide a way to submit 
security issues in a private way, there is a way to send people in the 
right direction for security disclosures. For a simple example : 
https://github.com/dask/dask-gateway/issues/new/choose where you can see 
the 3rd item can point to a separate URL explaining how to report 
security issues. These could either still be submitted to the 
bugs.php.net or could use a very simple captcha-enabled form (for 
anti-spam) that sends the report to specific people.


Kind regards,

Wim

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet

[Jakub Zelenka]

Hi,


> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>

+1, I have been dealing with bugsnet quite a bit as part of maintaining
openssl ext and FPM and it really sucks. Github issues are much better from
the maintainer point of view.


> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>

NodeJS uses hackerone which has got free plans for open source so that
might be an option. I'm sure there are more options and we don't have to
keep bugsnet for that too. But agree that starting with normal bugs and
requests is a way to go.


> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>

Lots of them are still valid though. At least the ones for openssl and fpm
that I track. It's not completely true that they are not going to be dealt
with. For example just recently Christoph made a PR for pkcs7 issue
reported in 2005 and I'm looking to the way how to write a test for it.
Just want to say that those are still valid and we will likely need some
kind of migration for many of those bugs even though OP is not active. It
could be just a tool that maintainers can use for selected bugs. I guess
just having some export in json for each bug would be great. Then the tool
to create a new issue and comments in gh would be easy - I could even write
it myself.. :)


> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>

Could we just leave it editable for VCS users only? That would help with
tracking and closing the migrated issues. It would eliminate spam so it
should be fine to keep it like that for some time.

Cheers

Jakub

Re: [PHP-DEV] Bugsnet

[Larry Garfield]

On Sun, May 9, 2021, at 1:48 AM, Joe Watkins wrote:
> Morning internals,
> 
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
> 
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.
> 
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
> 
> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
> 
> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
> 
> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
> 
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
> 
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on github.
> 
> I think we might get quite a good response here - anyone suffering the
> worst consequences of bugs - production servers can't be upgraded and so on
> - are already waiting for a notification from bugsnet, I'm sure the
> majority of them will do as we ask.
> 
> In some set number of weeks (to be decided), and depending on the response
> to our switching over to github, we can try to determine at that time if
> it's worth trying to import any data from bugsnet. We can also consider at
> this time when it might be appropriate to retire bugsnet entirely.
> 
> We will not be free of spam simply by moving, but github has the tools we
> need to moderate the content properly - you can block people. In addition,
> I feel people are less likely to misbehave if they think their co-workers
> or employers might be able to see what they are doing, which may have an
> effect also.
> 
> It may be over optimistic, but we might get better engagement with bugs on
> github than anywhere else also - Github is where people are tending to do
> their business today.
> 
> Github is maintained, hosted, developed, and free, and while it isn't the
> perfect tool for the job, nothing else is either. We could spend time
> (which we don't have) developing bugsnet, or installing some other solution
> in a dark corner of the internet, and solve no problems at all, and be
> burdened with the ongoing maintenance of that solution.
> 
> The people who have to spend the most time on this are release managers,
> and so while I'm talking to everyone, it is release managers opinions that
> I'm most interested in, they are the people who will be and have been most
> effected by the shortcomings in bugsnet, whose opinions are most relevant
> in this space.
> 
> I don't think a vote is appropriate, this decision should be made by the
> people whose "jobs" are directly effected - with input from the community,
> of course. Not least of all, it will take a month to close a vote, by which
> time we will have wasted another (working) day or more of Nikitas time.
> Having said all that, I am looking for a consensus before we take any
> action. My arm can be twisted, but this is my current position and I think
> it's a reasonable one.
> 
> On the issue of responsible disclosure ... we can treat this separately,
> with the recent change in the workflow, this process is in need of review
> anyway. How that is handled should be decided by the people who have a hand
> in that process, and so it seems prudent to leave it aside for now.
> 
> Cheers
> Joe

I agree with Joe that this is a decision that should be made mainly by the 
release managers, very-high-level contributors (Nikita, Dmitry, etc.), and 
whatever passes for sysadmins around here. :-)  As a fan of decoupling, 
however, I want to note that it sounds like there's a couple of separate issues 
involved here, for which GitHub is one possible solution.

Problem: The current system has a spam problem.
GitHub answer: GitHub has better anti-spam tools.
Alternatives/limitations: There are undoubtedly other tools that also have way 
better anti-spam tools, both SaaS and self-hosted.

Problem: No one can find the bloody thing.
GitHub 

RE: [PHP-DEV] Bugsnet

[André Hänsel]

You're talking about bugs.php.net, right? If you decide to move it, please 
leave the old one online in readonly mode. It's a valuable documentation 
resource.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet

[Kalle Sommer Nielsen]

Den søn. 9. maj 2021 kl. 09.49 skrev Joe Watkins :
>
> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.

Big +1 from my side. Much like Joe, I have tried a couple of times
over the years to keep the old bugsnet up to date, but it is simply
not possible to do in its current state -- for example, there is still
open feature requests from 2001 there. One can also open that it can
keep other spammers and abusers away from the platform such as the
ever so recurring abuse of Reindl Harald.

I only think the transition period will be difficult, but it should
iron itself out after a year or so (hopefully) and I assume that by
then, we could perhaps have a better medium or idea of how to deal
with security bugs based on the tools available to us after some time
of using Github on a project of the scale of PHP.

I also fully agree that it is not something we should vote on, it is
one of those things that those who actively work on PHP should decide
(to semi quote Rasmus) -- Let's make it happen.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet

[Sebastian Bergmann]

Am 09.05.2021 um 08:48 schrieb Joe Watkins:

Having moved our workflow to github, now seems to be the time to seriously
consider retiring bugsnet for general use, and using the tools that are
waiting for us - Github Issues.


Yes, please. Thank you for proposing this!


I propose that we disable bugsnet for all but security issues leaving
responsible disclosure method to be handled in some other way at a later
date. Leaving bugsnet in a (mostly) readonly mode.

We then send a notification to all bugs that were opened against a specific
and supported version of PHP, notifying the opener of the change and
requesting that they take a couple of minutes to open their issue on github.


Sounds reasonable to me.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Bugsnet

[Joe Watkins]

Morning internals,

We have a spam problem on bugsnet, it's not a new problem. Nikita had to
waste time deleting 20 odd messages from bugsnet yesterday and this is a
common, daily occurrence. We clearly don't have time for this.

Quite aside from spam problems, bugsnet is hidden away in a dark corner of
the internet that requires a special login, doesn't integrate with source
code or our current workflow (very nicely), and doesn't get updated or
developed.

Having moved our workflow to github, now seems to be the time to seriously
consider retiring bugsnet for general use, and using the tools that are
waiting for us - Github Issues.

I'm aware that bugsnet serves as the disclosure method for security bugs
and github doesn't have a solution to that. Leaving that to one side for
now ...

I'm also aware that bugsnet carries with it 20 years worth of crusty old
feature requests and bugs, that are never realistically going to be dealt
with. In the past I've spent time trying to close very old bugs that no
longer seem relevant, the fact is that there are so many of these that I
don't think I made a dent.

It seems obvious that we don't want to migrate all of the data on bugsnet,
but nor do we want to loose the most recent and relevant reports.

I propose that we disable bugsnet for all but security issues leaving
responsible disclosure method to be handled in some other way at a later
date. Leaving bugsnet in a (mostly) readonly mode.

We then send a notification to all bugs that were opened against a specific
and supported version of PHP, notifying the opener of the change and
requesting that they take a couple of minutes to open their issue on github.

I think we might get quite a good response here - anyone suffering the
worst consequences of bugs - production servers can't be upgraded and so on
- are already waiting for a notification from bugsnet, I'm sure the
majority of them will do as we ask.

In some set number of weeks (to be decided), and depending on the response
to our switching over to github, we can try to determine at that time if
it's worth trying to import any data from bugsnet. We can also consider at
this time when it might be appropriate to retire bugsnet entirely.

We will not be free of spam simply by moving, but github has the tools we
need to moderate the content properly - you can block people. In addition,
I feel people are less likely to misbehave if they think their co-workers
or employers might be able to see what they are doing, which may have an
effect also.

It may be over optimistic, but we might get better engagement with bugs on
github than anywhere else also - Github is where people are tending to do
their business today.

Github is maintained, hosted, developed, and free, and while it isn't the
perfect tool for the job, nothing else is either. We could spend time
(which we don't have) developing bugsnet, or installing some other solution
in a dark corner of the internet, and solve no problems at all, and be
burdened with the ongoing maintenance of that solution.

The people who have to spend the most time on this are release managers,
and so while I'm talking to everyone, it is release managers opinions that
I'm most interested in, they are the people who will be and have been most
effected by the shortcomings in bugsnet, whose opinions are most relevant
in this space.

I don't think a vote is appropriate, this decision should be made by the
people whose "jobs" are directly effected - with input from the community,
of course. Not least of all, it will take a month to close a vote, by which
time we will have wasted another (working) day or more of Nikitas time.
Having said all that, I am looking for a consensus before we take any
action. My arm can be twisted, but this is my current position and I think
it's a reasonable one.

On the issue of responsible disclosure ... we can treat this separately,
with the recent change in the workflow, this process is in need of review
anyway. How that is handled should be decided by the people who have a hand
in that process, and so it seems prudent to leave it aside for now.

Cheers
Joe

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Christoph M. Becker]

On 18.07.2019 at 16:25, Sara Golemon wrote:

> On Thu, Jul 18, 2019 at 6:10 AM Christoph M. Becker 
> wrote:
>
>> I agree that this would be the best solution in the long run, and it
>> shouldn't be hard to adapt ReasonRepository[1] to read from a file
>> instead of the DB.
>>
>> Any volunteers?
>>
>> [1]
>> <
>> http://git.php.net/?p=web/bugs.git;a=blob;f=src/Repository/ReasonRepository.php;h=b33d60a6bdae13dc78370aa24db481e1101ac13b;hb=HEAD
>
> Sure.
> https://github.com/php/web-bugs/commit/4b52935a8675d6ff6d5b06258e6c74ef135fad35

Thanks!

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Sara Golemon]

On Thu, Jul 18, 2019 at 6:10 AM Christoph M. Becker 
wrote:

> I agree that this would be the best solution in the long run, and it
> shouldn't be hard to adapt ReasonRepository[1] to read from a file
> instead of the DB.
>
> Any volunteers?
>
> [1]
> <
> http://git.php.net/?p=web/bugs.git;a=blob;f=src/Repository/ReasonRepository.php;h=b33d60a6bdae13dc78370aa24db481e1101ac13b;hb=HEAD
> >
>
> Sure.
https://github.com/php/web-bugs/commit/4b52935a8675d6ff6d5b06258e6c74ef135fad35

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Johannes Schlüter]

On Thu, 2019-07-18 at 12:24 +0100, Peter Cowburn wrote:
> I'm not sure if anyone other than us is still using this source code
> (looking at the MySQL guys).  If not, can we just include the reasons
> in
> the source directly, and forget about the database or a special file
> containing the reasons?
> 


MySQL's version heavily diverged 15+ years ago. No need to look at
compatibility. :-)

imo the php.net bug tracker should focus on php.net's needs.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Pieter Hordijk]

Hey all,

I think we can just add the reasons to the file where it is being rendered.

I am off for the weekend, but I can implement and test this after the weekend
if nobody else picked it up by then.

Pieter

- Original Message -
> From: "Peter Cowburn" 
> On Thu, 18 Jul 2019 at 12:10, Christoph M. Becker  wrote:
> 
>> On 18.07.2019 at 01:14, Stanislav Malyshev wrote:
>>
>> >> the quick fix descriptions of bugs.php.net[1] need some update.  To my
>> >> knowledge, these come from the database, so could anybody with access to
>> >> it please take a look?
>> >
>> > Ideally, I think this should be in PHP file and not database, so it will
>> > be modifyable by project members without needing shell access & DB
>> password.
>>
>> I agree that this would be the best solution in the long run, and it
>> shouldn't be hard to adapt ReasonRepository[1] to read from a file
>> instead of the DB.
>>
>> Any volunteers?
>>
> 
> I'm not sure if anyone other than us is still using this source code
> (looking at the MySQL guys).  If not, can we just include the reasons in
> the source directly, and forget about the database or a special file
> containing the reasons?
> 
> 
>>
>> [1]
>> <
>> http://git.php.net/?p=web/bugs.git;a=blob;f=src/Repository/ReasonRepository.php;h=b33d60a6bdae13dc78370aa24db481e1101ac13b;hb=HEAD
>> >
>>
>> Thanks,
>> Christoph
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Peter Cowburn]

On Thu, 18 Jul 2019 at 12:10, Christoph M. Becker  wrote:

> On 18.07.2019 at 01:14, Stanislav Malyshev wrote:
>
> >> the quick fix descriptions of bugs.php.net[1] need some update.  To my
> >> knowledge, these come from the database, so could anybody with access to
> >> it please take a look?
> >
> > Ideally, I think this should be in PHP file and not database, so it will
> > be modifyable by project members without needing shell access & DB
> password.
>
> I agree that this would be the best solution in the long run, and it
> shouldn't be hard to adapt ReasonRepository[1] to read from a file
> instead of the DB.
>
> Any volunteers?
>

I'm not sure if anyone other than us is still using this source code
(looking at the MySQL guys).  If not, can we just include the reasons in
the source directly, and forget about the database or a special file
containing the reasons?


>
> [1]
> <
> http://git.php.net/?p=web/bugs.git;a=blob;f=src/Repository/ReasonRepository.php;h=b33d60a6bdae13dc78370aa24db481e1101ac13b;hb=HEAD
> >
>
> Thanks,
> Christoph
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Christoph M. Becker]

On 18.07.2019 at 01:14, Stanislav Malyshev wrote:

>> the quick fix descriptions of bugs.php.net[1] need some update.  To my
>> knowledge, these come from the database, so could anybody with access to
>> it please take a look?
>
> Ideally, I think this should be in PHP file and not database, so it will
> be modifyable by project members without needing shell access & DB password.

I agree that this would be the best solution in the long run, and it
shouldn't be hard to adapt ReasonRepository[1] to read from a file
instead of the DB.

Any volunteers?

[1]


Thanks,
Christoph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Stanislav Malyshev]

Hi!

> the quick fix descriptions of bugs.php.net[1] need some update.  To my
> knowledge, these come from the database, so could anybody with access to
> it please take a look?

Ideally, I think this should be in PHP file and not database, so it will
be modifyable by project members without needing shell access & DB password.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Sara Golemon]

On Wed, Jul 17, 2019 at 4:19 AM Christoph M. Becker 
wrote:

> the quick fix descriptions of bugs.php.net[1] need some update.  To my
> knowledge, these come from the database, so could anybody with access to
> it please take a look?
>
>
Yep. bugdb_resolves table.
How about though, instead of requiring someone with direct DB karma to
update these, we just make an admin page for editing them directly on the
site (for a suitably limited population of logged in php.net users, of
course).
https://bugs.php.net/admin/?action=list_responses is halfway there, just
need a POST handler.

-Sara

[PHP-DEV] Bugsnet: Quick fix descriptions

[Christoph M. Becker]

Hi all,

the quick fix descriptions of bugs.php.net[1] need some update.  To my
knowledge, these come from the database, so could anybody with access to
it please take a look?

Details:

* Try a snapshot

There are no snapshots (except for Windows) any longer; it might make
sense to refer to Git.

* Fixed in SVN

Same as above.

* Fixed in SVN (Website problem)

There are no mirrors any more.

* Fixed in SVN (Doc Build problem)

There are no mirrors any more.

* PHP 4 support discontinued

There should be something like this for PHP 5

[1] 

Thanks,
Christoph

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugsnet cleanup

[Joe Watkins]

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

On Wed, Jan 18, 2017 at 1:21 PM, Ferenc Kovacs  wrote:

>
>
> On Sun, Jan 8, 2017 at 7:46 AM, Joe Watkins  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
>>
>
> 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
>

Re: [PHP-DEV] bugsnet cleanup

[Ferenc Kovacs]

On Sun, Jan 8, 2017 at 7:46 AM, Joe Watkins  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
>

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

Re: [PHP-DEV] bugsnet cleanup

[Maciej Sobaczewski]

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

2017-01-17 18:22 GMT+01:00 Andreas Heigl :


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



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.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugsnet cleanup

[Niklas Keller]

2017-01-17 18:22 GMT+01:00 Andreas Heigl :

> 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


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

Re: [PHP-DEV] bugsnet cleanup

[David Lundgren]

On 1/17/17 10:39 AM, Marco Pivetta wrote:
> On Tue, Jan 17, 2017 at 5:35 PM, Stanislav Malyshev 
> 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
dlundg...@syberisle.net
GPG: 0x26F54D7F



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] bugsnet cleanup

[Andreas Heigl]

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:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PHP-DEV] bugsnet cleanup

[Stanislav Malyshev]

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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugsnet cleanup

[Stanislav Malyshev]

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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugsnet cleanup

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

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugsnet cleanup

[Marco Pivetta]

On Tue, Jan 17, 2017 at 5:35 PM, Stanislav Malyshev 
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/

Re: [PHP-DEV] bugsnet cleanup

[Stanislav Malyshev]

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 
> 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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugsnet cleanup

[Marco Pivetta]

On Tue, Jan 17, 2017 at 9:19 AM, Joe Watkins  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/

Re: [PHP-DEV] bugsnet cleanup

[Joe Watkins]

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

Re: [PHP-DEV] bugsnet cleanup

[Stanislav Malyshev]

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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugsnet cleanup

[Jakub Zelenka]

On Mon, Jan 9, 2017 at 10:10 AM, Andreas Heigl  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 
> 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

Re: [PHP-DEV] bugsnet cleanup

[Jakub Zelenka]

On Mon, Jan 9, 2017 at 10:04 AM, Remi Collet  wrote:

> Le 09/01/2017 à 10:59, Jakub Zelenka a écrit :
> > Hi,
> >
> > On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet 
> 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".

Re: [PHP-DEV] bugsnet cleanup

[Andreas Heigl]

Hi Jakub.

Am 09.01.17 um 10:59 schrieb Jakub Zelenka:
> Hi,
> 
> On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet  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:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PHP-DEV] bugsnet cleanup

[Remi Collet]

Le 09/01/2017 à 10:59, Jakub Zelenka a écrit :
> Hi,
> 
> On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet  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 ;)




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] bugsnet cleanup

[Jakub Zelenka]

Hi,

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

Re: [PHP-DEV] bugsnet cleanup

[Joe Watkins]

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

Re: [PHP-DEV] bugsnet cleanup

[Remi Collet]

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;





signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] bugsnet cleanup

[Joe Watkins]

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

> Morning Joe
>
> 2017-01-09 7:13 GMT+01:00 Joe Watkins :
> > 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
> ka...@php.net
>

Re: [PHP-DEV] bugsnet cleanup

[Kalle Sommer Nielsen]

Morning Joe

2017-01-09 7:13 GMT+01:00 Joe Watkins :
> 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
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugsnet cleanup

[Joe Watkins]

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 
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
> smalys...@gmail.com
>

Re: [PHP-DEV] bugsnet cleanup

[Stanislav Malyshev]

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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugsnet cleanup

[Stanislav Malyshev]

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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugsnet cleanup

[Andreas Heigl]

Hi all.

Am 08.01.17 um 11:29 schrieb Nikita Popov:
> On Jan 8, 2017 7:47 AM, "Joe Watkins"  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:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PHP-DEV] bugsnet cleanup

[Joe Watkins]

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

> On Jan 8, 2017 7:47 AM, "Joe Watkins"  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
>

Re: [PHP-DEV] bugsnet cleanup

[Nikita Popov]

On Jan 8, 2017 7:47 AM, "Joe Watkins"  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

Re: [PHP-DEV] bugsnet cleanup

[Sebastian Bergmann]

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

[PHP-DEV] bugsnet cleanup

[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