[PHP-DEV] Re: Bugsnet

[Pierre Joye]

Hi Joe,

On Sun, May 9, 2021, 1:49 PM Joe Watkins  wrote:

> Morning internals,
>
>
> 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! yes! yes!

and we could you projects/roadmap too together with gh APIs and the RFC.

>

Re: [PHP-DEV] Re: Bugsnet

[Pierre Joye]

Hi Stas,

On Sun, May 9, 2021, 3:06 PM Stanislav Malyshev  wrote:

> Hi!
>
> > If at some time in the future, github becomes a less than suitable
> > environment for us, we can just move, no problem. There's no sense in
> > which we are locked into anything.
>
> I don't see how we could "just move" if all our bug handling would be
> wired into Github. I can easily see how we could move a repo to any
> provider that supports git - git is a generic platform, Github is just a
> frontend. But there's no alternative frontend for Github Issues that we
> could just copy the data into - you move, you lose your existing system.
>   There are probably import tools on some platforms, but the processes,
> assignments, etc. - all will have to be re-developed, even if we could
> re-use the raw data.
>


You and Joe make very good points here. Many moons ago, I was looking to
replace bugsnet with a managed, powerful solutions. There were not much.

These days there many very very good ones, custom flows, statuses, link to
emails,  private sections or tickets.  I would suggest to look into this
instead (f.e. I am a big fan of clickup ;).


best,



> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Bugsnet

[Nikita Popov]

On Tue, May 25, 2021 at 3:10 PM Christoph M. Becker 
wrote:

> On 25.05.2021 at 14:57, Nikita Popov wrote:
>
> > To make some forward progress here, I think a good starting point would
> be
> > to enable GitHub issues on the doc-* repos to get some usage experience
> in
> > a more limited setting. Docs issues probably benefit more from being
> hosted
> > on GitHub than php-src issues, as this is an area where 3rd-party
> > contributors can easily pick up issues they can address.
>
> Agreed (maybe start with doc-en only for now; there are not that many
> translation issues anyway).  Feel free to open the issues right away.
>

Okay, I've done that.

I think it would make sense to have issues on the translation repos as well
(at least the active ones). One thing that github issue templates support
is simple links, which means we could have something like:

 * Report incorrect documentation (<- normal issue with tag)
 * Report missing documentation (<- normal issue with tag)
 * Report incorrect German translation (<-> links to doc-de issue tracker)
 * etc.

Though we can consider something like that later as well.


> > If all goes well, we can disable submission of "Documentation Problem"
> bugs
> > in bugsnet and consider how to move forward with php-src.
>
> One particular problem would be issues filed as bug, but are
> reclassified as doc problem.  We likely would need a bot to "transfer"
> these issues to doc-en.
>

Yeah, that's going to be a problem with any kind of partial migration.

Regards,
Nikita

Re: [PHP-DEV] Re: Bugsnet

[Christoph M. Becker]

On 25.05.2021 at 14:57, Nikita Popov wrote:

> To make some forward progress here, I think a good starting point would be
> to enable GitHub issues on the doc-* repos to get some usage experience in
> a more limited setting. Docs issues probably benefit more from being hosted
> on GitHub than php-src issues, as this is an area where 3rd-party
> contributors can easily pick up issues they can address.

Agreed (maybe start with doc-en only for now; there are not that many
translation issues anyway).  Feel free to open the issues right away.

> If all goes well, we can disable submission of "Documentation Problem" bugs
> in bugsnet and consider how to move forward with php-src.

One particular problem would be issues filed as bug, but are
reclassified as doc problem.  We likely would need a bot to "transfer"
these issues to doc-en.

Christoph

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

Re: [PHP-DEV] Re: Bugsnet

[Nikita Popov]

On Mon, May 10, 2021 at 11:22 PM Christoph M. Becker 
wrote:

> On 10.05.2021 at 17:10, Nikita Popov wrote:
>
> >  * As was already mentioned, there's no support for security issues, so
> > we'd retain bugs.php.net for that purpose, at least for the time being.
>
> But even if bugsnet would no longer be required to file any new tickets,
> please keep it in read-only mode.
>
> >  * It's worth noting that issues are per-repository, which means that
> > documentation issues will now live in the doc repo(s), and PECL issues in
> > the PECL repos. php-src will only have issues relating to php-src
> > specifically. This is great.
>
> ACK.
>
> >  * The minimum minor PHP version affected should probably also be
> specified
> > through a label -- I don't personally search issues by version, but other
> > people (cmb?) might. If search by version is not common, we can have this
> > information only in the issue description. The operating system can be a
> > label as well, though we should only add that if the issue is actually
> > OS-specific -- this is pretty rare.
>
> I rarely search by version; I think I did that as RM during the
> pre-release phase of 7.3.  Most often the version info is pretty
> irrelevant, since the issue affects all supported PHP versions.  In my
> opinion, having the PHP version in the bug description is good enough
> for now; we still can add labels if that turns out to be useful.
>
> >   a) I pretty much never look at bug votes -- though GitHub has
> thumbs-up,
> > thumbs-down as an equivalent there.
>
> I would actually prefer the GH reactions.  The voting feature might
> still be broken, anyway.
>
> > TL;DR Yes, I do think switching from bugs.php.net to GitHub issues
> would be
> > beneficial for the project. Details on how to do that need to be ironed
> > out, but I think the direction is the right one.
>
> I'm +0.5 on this.


To make some forward progress here, I think a good starting point would be
to enable GitHub issues on the doc-* repos to get some usage experience in
a more limited setting. Docs issues probably benefit more from being hosted
on GitHub than php-src issues, as this is an area where 3rd-party
contributors can easily pick up issues they can address.

If all goes well, we can disable submission of "Documentation Problem" bugs
in bugsnet and consider how to move forward with php-src.

Regards,
Nikita

Re: [PHP-DEV] Re: Bugsnet

[Christoph M. Becker]

On 10.05.2021 at 17:10, Nikita Popov wrote:

>  * As was already mentioned, there's no support for security issues, so
> we'd retain bugs.php.net for that purpose, at least for the time being.

But even if bugsnet would no longer be required to file any new tickets,
please keep it in read-only mode.

>  * It's worth noting that issues are per-repository, which means that
> documentation issues will now live in the doc repo(s), and PECL issues in
> the PECL repos. php-src will only have issues relating to php-src
> specifically. This is great.

ACK.

>  * The minimum minor PHP version affected should probably also be specified
> through a label -- I don't personally search issues by version, but other
> people (cmb?) might. If search by version is not common, we can have this
> information only in the issue description. The operating system can be a
> label as well, though we should only add that if the issue is actually
> OS-specific -- this is pretty rare.

I rarely search by version; I think I did that as RM during the
pre-release phase of 7.3.  Most often the version info is pretty
irrelevant, since the issue affects all supported PHP versions.  In my
opinion, having the PHP version in the bug description is good enough
for now; we still can add labels if that turns out to be useful.

>   a) I pretty much never look at bug votes -- though GitHub has thumbs-up,
> thumbs-down as an equivalent there.

I would actually prefer the GH reactions.  The voting feature might
still be broken, anyway.

> TL;DR Yes, I do think switching from bugs.php.net to GitHub issues would be
> beneficial for the project. Details on how to do that need to be ironed
> out, but I think the direction is the right one.

I'm +0.5 on this.

--
Christoph M. Becker

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

Re: [PHP-DEV] Re: Bugsnet

[Rowan Tommins]

On 10/05/2021 16:10, Nikita Popov wrote:

Did I miss anything else that bugs.php.net  does?



The biggest difference I see between GH Issues and every other issue 
tracker I've ever seen is pre-defined fields. Labels can broadly do the 
same job, but they feel very different when managing them, composing 
search queries, and viewing search results.


The fields on the Advanced Search for bugs.php.net are currently:

* Status - GH has only "Open" and "Closed"; we'd probably want a set of 
"Status-..." labels
* Type - "Feature Request" is probably fine as a label; "Documentation 
Problem" would probably be the doc-en issue tracker, but I don't know 
how easily issues can be moved from one project to another during triage
* Project - PHP or PECL; again, possible requirement to move issues 
between projects?
* Package - as you say, this is a long and unwieldy list right now, but 
one that needs to exist in some form (i.e. re-organizing it to a smaller 
list is somewhat orthogonal to moving to a different platform)

* OS - makes sense as optional labels for "Windows-specific" etc
* PHP Version - as you mention, what to do with this depends how people 
use it (and also how reliable it is)

* CVE-ID - irrelevant if security issues are going somewhere else
* Assigned - exists in Github!
* Author email - exists in Github!
* Has patch - redundant
* Has pull request - not sure if you can search on this in Github, or if 
we'd have to add a manual label (again, this is the kind of thing a lot 
of projects maintain bots for)

* Commented by - exists in Github!


Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] Re: Bugsnet

[Nikita Popov]

On Mon, May 10, 2021 at 3:29 PM Dan Ackroyd  wrote:

> Hi Joe,
>
> > We have a spam problem on bugsnet
>
> I would snarkily say "maybe accept the PRs from people wanting to work
> on it?", but I realise that ignores the underlying problem, that PHP
> lacks people. And particularly lacks people who can dedicate time to
> understanding, reviewing and saying no to things.
>

Yes, I think this is something people often don't get: It's not just a
matter of finding someone who can implement a change, but also someone who
is willing to review it, and someone who can perform necessary
infrastructure changes, such as server configuration changes or database
migrations. The last part is where things commonly fail.

Even if the plan is to move to a different platform, I'd like to take
> the time to document what is lacking about bugs.php.net currently.
> Please can someone turn on issues for php/web-bugs?
>

Ha, this is a great illustration. You do realize that the bug tracker for
bugs.php.net is bugs.php.net? Under the "General issues - PHP.net Website
problem" category, I believe. However, bugs.php.net is really not suitable
for the kind of use you have in mind. And this also extends to other areas.
For example, for php-src we sometimes use
https://github.com/php/php-tasks/issues to track and coordinate certain
changes, because bugs.php.net is very inconvenient for that purpose.

So, here's my 2c on the proposal. Let me start with issues I see with
bugs.php.net:

 * bugs.php.net is regularly semi-down (slow to the point of being
unusable). Either Derick or myself regularly restart the server to recover
it. I don't believe anyone ever looked into the cause.

 * There is a lot of linkspam, and it's getting worse. I delete a few
comments ever day. On some days it's just a few, on some days it's dozens.
This is something that *can* likely be addressed, but may degrade user
experience further, e.g. with recaptcha, which is notoriously finicky.

 * Next to linkspam, we unfortunately also suffer from hostile user
comments from one Reindl Harald. This user is banned from the mailing list
and our GitHub organization, but we are not able to effectively ban him
from bugs.php.net, because it requires no form of authentication
whatsoever. You can enter an arbitrary email. I think many people don't
appreciate it, but this is actually a ***really big problem***. This user
is consistently and routinely very rude to bug reports, which hurts the
overall reputation of the PHP project. While it should be clear that he
does not represent the PHP project, it still remains a fact that that if
you submit a bug on bugs.php.net, you are quite likely to get some insults
thrown at you. This is not great.

 * I think to resolve the previous point (and linkspam as well), we need to
require authentication on bugs.php.net, which would further degrade user
experience. As part of the git.php.net/master.php.net incident response, we
also discussed whether we could move bugs.php.net to authenticate using
GitHub, now that all PHP contributors need to be part of the PHP GitHub
organization. I think if we wanted to retain bugs.php.net, we'd have to
pursue something in this direction, with all users required to authenticate
through GitHub.

 * For me personally, as a developer with a php.net account, bugs.php.net
is actually a somewhat okay system. I think the main people suffering from
it are bug reporters not affiliated with php.net. One reason is that
there's no good way to manage your reported bugs -- the only thing you get
is a per-bug (!) password to edit it later, bug you can't track bugs you
reported or similar.

 * Bug reports are submitted with incorrect categories very often. I can't
really blame the reporters for that, because there's a *lot* of them, and
they're grouped, so it's really not easy to find the right one (even for
me). This is common to the point that I would consider the inability of the
reporter to specify category/label on GitHub a feature rather than a bug --
this is something that should be done by someone during triage, who is
familiar with the available categories/labels.

 * bugs.php.net does not support checkboxes or edits to the bug
description, which makes it completely unsuitable for tracking issues and
any kind of coordination works (this is part of the reason why the
php-tasks tracker exists).

 * bugs.php.net does not support labels -- only top-level categorization.
For example, we can't mark bugs as "probably easy" or "good first issue" to
give newbies something to chew on.

GitHub issues address most of these concerns, and are tightly integrated
with the pull request workflow. GitHub issues is not the most advanced bug
tracker out there, but the unfortunate truth is that it's still much better
than bugs.php.net. Some thoughts on how our usage would look like:

 * As was already mentioned, there's no support for security issues, so
we'd retain bugs.php.net for that purpose, at least for the time being.

 * 

Re: [PHP-DEV] Re: Bugsnet

[Dan Ackroyd]

Hi Joe,

> We have a spam problem on bugsnet

I would snarkily say "maybe accept the PRs from people wanting to work
on it?", but I realise that ignores the underlying problem, that PHP
lacks people. And particularly lacks people who can dedicate time to
understanding, reviewing and saying no to things.

Even if the plan is to move to a different platform, I'd like to take
the time to document what is lacking about bugs.php.net currently.
Please can someone turn on issues for php/web-bugs?

My two concerns with moving to using other systems would be:

* it'd be really useful to be able to authenticate php.net account
holders on other systems, rather than having to set everyone's
permissions up on each system by hand. I believe Saif may have been
thinking about this a bit.

* the low barrier to 'chipping in' through github issues and PRs have
not been a joyous occasion for me. There is a really high proportion
of "non-productive" contributions e.g. people 'approving PRs' for
libraries they are not involved with, or flaming other users. Although
moving to github issues will solve some annoying problems, that might
be balanced by a larger number of slightly less annoying problems.

But sure, the current situation is rubbish and moving issue tracking
to github seems at least worth trying.

Rowan Tommins wrote:
> In terms of "SaaS vs custom code", it's notable that all three run
> custom bots to add functionality not offered by Github,

Yeah, unfortunately Github has focused more on making the barrier to
using Github low, rather than making it easy to implement access
control for non-enterprise customers.

> It might just be an illusion, but it feels like all three projects have
> a lot more resources to spend on all this than PHP does;

I know for various reasons PHP doesn't have a foundation behind it,
but if there was one, it's the boring stuff that a foundation should
be looking at doing:

* maintaining and improving infrastructure.
* writing documentation and helping people learn PHP internals.
* gathering feedback and summarising it.
* maintaining a list of items that could be worked on.

None of those things are a good fit for being maintained long-term on
an ad-hoc basis.

cheers
Dan
Ack

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

[PHP-DEV] Re: Bugsnet

[Derick Rethans]

Hi Joe,

I don't think anybody denies that bugsnet isn't great, and that spam is 
an issue. I would argue that the main reason for the spam is, is that we 
don't require a sign-up. But I think we need to be really careful if 
we'd decide to move to something else.


TLDR: I don't believe GitHub issues is suitable, neither feature wise or 
future-safety wise. We need to be sensible about both items if we 
decided to move to a different issue tracker.


Right now, bugs has several features that GitHub issues doesn't provide: 
multiple statusses, categories (of which bugsnet has a *lot*), and 
dedicated fields for the PHP version etc.

I know that the PHP version can be done through a issue template, and 
that the categories can be done with labels. But in order to represent 
the same rich category information, and hence be able to search on bugs 
in a specific category (such as "DateTime", you'd need a label each for 
each current category.

Having to maintain these labels, and setting them correctly on issues, 
is perhaps going to be more work than removing spam. I'm sure we can 
make it work *somewhat*, but it is going to be a degradation of what 
bugsnet does. On top of that, we'll have to install/configure build 
automation, such as our "quick closes", or the "closed after 3 weeks of 
inactivity".

And I think somebody else mentioned this already, but I am going to 
expect that people will use the issue tracker for support questions as 
well. It has been the case for every GH repository that I had issues 
enabled on.


The other important issue is to consider the continuation of the 
availability of the platform. Bugsnet has been running for 23 years. 
While that unfortunately means that some of the code is that old, it is 
IMO a stellar track record.

Is GitHub Issues going to be around in a way that we want it in another 
23 years? And, if GHI is going a way we don't want it to go in in say 5 
years, is it possible to switch easily to something else?

This isn't really a problem with the code repository itself, as it's 
easy enough to clone and move somewhere else. But that is *not* the case 
for GHI. AFAIK, you can't either import or export easily into/out of it, 
and most definitely not in the rich format that we currently have in 
bugsnet.


I did actually experiment with GitHub Issues for Xdebug, and decided 
that even for that small a project, it wasn't really suitable due to the 
feature set, and that's basically just *me* using it.

I currently use Mantis, which although it has it's minor issues, works 
actually really well. I can host it myself, although they can provide a 
hosted service, and it's actively maintained, and written in PHP. 



cheers,
Derick

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Re: Bugsnet

[Stanislav Malyshev]

Hi!

It might just be an illusion, but it feels like all three projects have 
a lot more resources to spend on all this than PHP does; Rust has 
"Working Groups", Kubernetes has "Special Interest Groups", and PHP 
struggles to assign each module a single maintainer. How that affects 
our tooling requirements, I'm not sure, but I suspect new contributor 
experience should be high on our priority list, either in terms of user 
interface or just documentation.


Great survey. I do not have much experience with others, but from my 
observations about Prow it's a software system of its own which needs 
its own configuration, setup, maintenance, and everything else that's 
involved in setting up and maintaining CI/CD system. Github provides a 
nice GUI for it but there's much more that is happening behind the 
scenes than the GUI. Prow itself is pretty nice to use, once you learn 
how to work with it, but we need to be aware that if we want something 
with Prow capabilities, we'd need somebody willing to support this 
system, so we're back to the same place we departed from.


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

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

Re: [PHP-DEV] Re: Bugsnet

[Rowan Tommins]

On 09/05/2021 16:30, Max Semenik wrote:
Lots of large projects use GitHub for bug tracking: Go, Rust, 
Kubernetes - seems to work well enough for them.



Those three look like good examples in terms of volume. It's hard to 
tell from the outside if people are happy with their processes, but we 
can get some idea of what those processes are, and whether PHP could do 
something similar.


In terms of "SaaS vs custom code", it's notable that all three run 
custom bots to add functionality not offered by Github, with both 
automatic actions (e.g. adding default labels, closing stale issues) and 
interactive ones (e.g. adding certain labels at user request, without 
the user needing permission in Github itself). Rust's bot is strongly 
integrated with their Zulip chat instance; Kubernetes' bot is part of 
the Prow CI application.


- https://github.com/golang/build/blob/master/cmd/gopherbot/gopherbot.go
- https://github.com/rust-lang/triagebot
- https://github.com/kubernetes/test-infra/tree/master/prow#bots-home

Go makes heavy use of Milestones; my impression is that these are 
assigned by Google employees working on the project full time.


Kubernetes and Rust both use prefixed labels for various attributes of 
the issue (Area, Status, Severity, etc): Kubernetes has a total of 196; 
Rust has a whopping 376, the best description I found of which is this: 
https://internals.rust-lang.org/t/how-the-rust-issue-tracker-works/3951


It might just be an illusion, but it feels like all three projects have 
a lot more resources to spend on all this than PHP does; Rust has 
"Working Groups", Kubernetes has "Special Interest Groups", and PHP 
struggles to assign each module a single maintainer. How that affects 
our tooling requirements, I'm not sure, but I suspect new contributor 
experience should be high on our priority list, either in terms of user 
interface or just documentation.


Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] Re: Bugsnet

[Max Semenik]

On Sun, May 9, 2021 at 11:58 AM Rowan Tommins 
wrote:

> Can we do a throwaway import of a few hundred bugs to a test repo, and see
> what that might look like?


Is there a dump of public issues available somewhere?

The closest to sufficient data export I can find is e.g.
https://bugs.php.net/rss/bug.php?id=70549=xml but it lacks comments
even though the code is supposed to include them too.

-- 
Best regards,
Max Semenik

Re: [PHP-DEV] Re: Bugsnet

[Max Semenik]

On Sun, May 9, 2021 at 11:58 AM Rowan Tommins 
wrote:

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


Lots of large projects use GitHub for bug tracking: Go, Rust, Kubernetes -
seems to work well enough for them.


> Are we better off looking for a SaaS that can provide something more
> full-featured - Mantis, Phabricator, Trac, Bugzilla, YouTrack, etc?
>

Half of these (Mantis, Trac and especially Bugzilla) are already obsolete,
migrating to either of them wouldn't be future-proof. If some people here
doubt the future of GitHub, probably only Atlassian or JetBrains SaaS
solutions can be assumed to be on the same order of magnitude of longevity
as GH.


-- 
Best regards,
Max Semenik

[PHP-DEV] Re: Bugsnet

[Mark Randall]

On 09/05/2021 09:05, Stanislav Malyshev wrote:
I don't see how we could "just move" if all our bug handling would be 
wired into Github. I can easily see how we could move a repo to any 
provider that supports git - git is a generic platform, Github is just a 
frontend. But there's no alternative frontend for Github Issues that we 
could just copy the data into - you move, you lose your existing system. 
There are probably import tools on some platforms, but the processes, 
assignments, etc. - all will have to be re-developed, even if we could 
re-use the raw data.



If Github does something so outrageous that a move is required, it is 
unlikely to just be PHP that is affected.


Such an eventuality would be all but certain to result in a huge 
cross-community effort to develop automated migration tools.


Tools such as github already have integrations that allow migrating 
Github data into their own formats.


I personally am not at all worried about having bugs on github.

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

Re: [PHP-DEV] Re: Bugsnet

[Rowan Tommins]

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?

It would probably be a useful exercise to mock up *how* we would use it - I'm 
guessing there'd be a long list of custom tags, since that's pretty much the 
only thing you can use for organising issues. I've seen some projects use 
prefixed tags like "01 - Component: XML" to simulate a hierarchy.

At a glance, it seems we get as many as 100 non-spam bugs a month, so even if 
we don't migrate anything, we're potentially into the thousands within a couple 
of years. Can we do a throwaway import of a few hundred bugs to a test repo, 
and see what that might look like?

Regards,

-- 
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] Re: Bugsnet

[Joe Watkins]

Hi all,

I shouldn't have said we can "just" move ... I'm not supposing it will be
easy.

We can "just move", in about the same sense that we can "just move" today.

Considering the difficulty of problems we do not currently have is a waste
of time.

Cheers
Joe

On Sun, 9 May 2021 at 10:08, Andreas Heigl  wrote:

> Hey folks:
>
> Am 09.05.21 um 09:33 schrieb Stanislav Malyshev:
> > Hi!
> >
> [...]
> >
> > 1. Bug reporting templates> 2. Pre-filter on reported bugs> 3. Advanced
> search
> > 4. Custom fields like PHP version or CVE ID
> > 5. Private bugs that are accessible only to members of security team
> > 6. Custom statuses (I guess can be worked around with labels, but would
> > require a lot of work to make it convenient to use, default screen would
> > be pretty much unusable due to clutter, as it only understands
> closed/open)
> > 7. Ability for anybody to submit a bug without opening github account
> > (yes, I know it also produces the spam problem) and assigning bugs to
> > people that don't have github account (we still can accept patches from
> > those, can't we?).
> > 8. Statistics
> >
> >> 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.
> >
> > I think it's way to generic statement. Some people choose github for
> > doing some stuff would be more accurate. I don't think I can remember
> > from the top of my head any major project that uses Github as their main
> > bug tracker. Maybe they exist, but I certainly can't recall any.
> >
> >> 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.
> >
> > Why we must install it in a dark corner? Maybe we should ask for some
> > help from people who are willing to contribute before we decide to scrap
> > the whole thing.
> >
> > Besides that, I am not sure I am feeling that comfortable with moving
> > 100% of the infrastructure of the PHP project to a platform wholly owned
> > by Microsoft, and that's where things seem to be heading. I know
> > Microsoft is almost not evil now, and it has no problem with PHP
> > whatsoever, but things change, and who knows what would happen in
> > another 5-10 years. I am not sure hard-binding the whole project to a
> > single platform owned by a single company is that great. Due to the
> > distributed nature of Git, the repository hosting is very low risk - it
> > could be easily moved anywhere. But having the rest of the
> > infrastructure in a single point of failure does not feel great. Once we
> > move in there, it would be very hard to move out.
>
> This is for me the most interesting point. While it is rather easy to
> move fastly away from Github with the source-code it will be much more
> complicated to move to "somewhere else" with all of the issues.
>
> Yes, we currently have the same problem with PRs but not "owning" our
> bug-report system feels ... not right to me. Especially when there is no
> way to actually turning it off due to the security bugs.
>
> While on the other hand I think it absolutely great to have another
> infrastructure part that we do not have to maintain!
>
> My prefered way to go would be some other bug-reporting SaaS that can
> integrate with github but can provide some more of what we currently
> have and that also allows us to also use it for security related issues.
>
> 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" |
> | https://andreas.heigl.org  https://hei.gl/where |
> |https://hei.gl/pubkeyandreas |
> +-+
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Bugsnet

[Andreas Heigl]

Hey folks:

Am 09.05.21 um 09:33 schrieb Stanislav Malyshev:
> Hi!
> 
[...]
> 
> 1. Bug reporting templates> 2. Pre-filter on reported bugs> 3. Advanced search
> 4. Custom fields like PHP version or CVE ID
> 5. Private bugs that are accessible only to members of security team
> 6. Custom statuses (I guess can be worked around with labels, but would
> require a lot of work to make it convenient to use, default screen would
> be pretty much unusable due to clutter, as it only understands closed/open)
> 7. Ability for anybody to submit a bug without opening github account
> (yes, I know it also produces the spam problem) and assigning bugs to
> people that don't have github account (we still can accept patches from
> those, can't we?).
> 8. Statistics
> 
>> 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.
> 
> I think it's way to generic statement. Some people choose github for
> doing some stuff would be more accurate. I don't think I can remember
> from the top of my head any major project that uses Github as their main
> bug tracker. Maybe they exist, but I certainly can't recall any.
> 
>> 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.
> 
> Why we must install it in a dark corner? Maybe we should ask for some
> help from people who are willing to contribute before we decide to scrap
> the whole thing.
> 
> Besides that, I am not sure I am feeling that comfortable with moving
> 100% of the infrastructure of the PHP project to a platform wholly owned
> by Microsoft, and that's where things seem to be heading. I know
> Microsoft is almost not evil now, and it has no problem with PHP
> whatsoever, but things change, and who knows what would happen in
> another 5-10 years. I am not sure hard-binding the whole project to a
> single platform owned by a single company is that great. Due to the
> distributed nature of Git, the repository hosting is very low risk - it
> could be easily moved anywhere. But having the rest of the
> infrastructure in a single point of failure does not feel great. Once we
> move in there, it would be very hard to move out.

This is for me the most interesting point. While it is rather easy to
move fastly away from Github with the source-code it will be much more
complicated to move to "somewhere else" with all of the issues.

Yes, we currently have the same problem with PRs but not "owning" our
bug-report system feels ... not right to me. Especially when there is no
way to actually turning it off due to the security bugs.

While on the other hand I think it absolutely great to have another
infrastructure part that we do not have to maintain!

My prefered way to go would be some other bug-reporting SaaS that can
integrate with github but can provide some more of what we currently
have and that also allows us to also use it for security related issues.

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" |
| https://andreas.heigl.org  https://hei.gl/where |
|https://hei.gl/pubkeyandreas |
+-+

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

[PHP-DEV] Re: Bugsnet

[Stanislav Malyshev]

Hi!

If at some time in the future, github becomes a less than suitable 
environment for us, we can just move, no problem. There's no sense in 
which we are locked into anything.


I don't see how we could "just move" if all our bug handling would be 
wired into Github. I can easily see how we could move a repo to any 
provider that supports git - git is a generic platform, Github is just a 
frontend. But there's no alternative frontend for Github Issues that we 
could just copy the data into - you move, you lose your existing system. 
 There are probably import tools on some platforms, but the processes, 
assignments, etc. - all will have to be re-developed, even if we could 
re-use the raw data.


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

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

[PHP-DEV] Re: Bugsnet

[Joe Watkins]

Hi Stas,

I did mention that we're leaving aside the sec issue for now.

>  Let me list all it is lacking that
we have right now, with current old and dusty bugs:

1)
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository
2) Not sure what this means ?
3) The interface sucks a little, but the options are mostly supported:
https://docs.github.com/en/github/searching-for-information-on-github/searching-issues-and-pull-requests
4 & 6) Tags seem to be the solution here
7) What appears a disadvantage to you appears to be an advantage to me.

> I am not sure I am feeling that comfortable with moving
100% of the infrastructure of the PHP project to a platform wholly owned
by Microsoft,

Sorry, but this sounds like paranoia that I'm not willing to engage.

> who knows what would happen in another 5-10 years

It's true, things change, let's deal with the problems we actually have,
instead of ones we imagine might happen.

> I am not sure hard-binding the whole project to a single platform owned
by a single company is that great.

At one time, all of the infrastructure being under our control, which you
think is ideal, actually meant that the infrastructure for one of the most
important pieces of tech on the web was
surviving on handouts, with not enough resources to maintain or develop the
software we, and so everybody else, was relying on.

We are suffering the direct consequences of these decisions today.

If at some time in the future, github becomes a less than suitable
environment for us, we can just move, no problem. There's no sense in which
we are locked into anything.

> Maybe it's just my paranoia speaking

It seems like we agree :D

We need to make things better, and I'm not saying that github is perfect or
I have all the answers, but feel strongly that we'll be better served by
moving right now.

Thanks for input Stas ...

Cheers
Joe


On Sun, 9 May 2021 at 09:33, Stanislav Malyshev  wrote:

> Hi!
>
> > 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 know my opinion here probably doesn't carry a lot of weight since I am
> not the one maintaining bugs day to day (and probably don't have much
> time to allocate to it) but that's what I've got.
>
> 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. Let me list all it is lacking that
> we have right now, with current old and dusty bugs:
>
> 1. Bug reporting template
> 2. Pre-filter on reported bugs
> 3. Advanced search
> 4. Custom fields like PHP version or CVE ID
> 5. Private bugs that are accessible only to members of security team
> 6. Custom statuses (I guess can be worked around with labels, but would
> require a lot of work to make it convenient to use, default screen would
> be pretty much unusable due to clutter, as it only understands closed/open)
> 7. Ability for anybody to submit a bug without opening github account
> (yes, I know it also produces the spam problem) and assigning bugs to
> people that don't have github account (we still can accept patches from
> those, can't we?).
> 8. Statistics
>
> > 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.
>
> I think it's way to generic statement. Some people choose github for
> doing some stuff would be more accurate. I don't think I can remember
> from the top of my head any major project that uses Github as their main
> bug tracker. Maybe they exist, but I certainly can't recall any.
>
> > 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.
>
> Why we must install it in a dark corner? Maybe we should ask for some
> help from people who are willing to contribute before we decide to scrap
> the whole thing.
>
> Besides that, I am not sure I am feeling that comfortable with moving
> 100% of the infrastructure of the PHP project to a platform wholly owned
> by 

Re: [PHP-DEV] Re: Bugsnet

[Sebastian Bergmann]

Am 09.05.2021 um 09:33 schrieb Stanislav Malyshev:

1. Bug reporting template


GitHub Issues has support for reporting templates.

For instance, clicking "New issue" on 
https://github.com/symfony/symfony/issues will lead to you 
https://github.com/symfony/symfony/issues/new/choose. This is an overview 
of the reporting templates supported by the Symfony project.


These templates are managed in version control: 
https://github.com/symfony/symfony/tree/5.x/.github/ISSUE_TEMPLATE


The feature is documented here: 
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository


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

[PHP-DEV] Re: Bugsnet

[Stanislav Malyshev]

Hi!

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 know my opinion here probably doesn't carry a lot of weight since I am 
not the one maintaining bugs day to day (and probably don't have much 
time to allocate to it) but that's what I've got.


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. Let me list all it is lacking that 
we have right now, with current old and dusty bugs:


1. Bug reporting template
2. Pre-filter on reported bugs
3. Advanced search
4. Custom fields like PHP version or CVE ID
5. Private bugs that are accessible only to members of security team
6. Custom statuses (I guess can be worked around with labels, but would 
require a lot of work to make it convenient to use, default screen would 
be pretty much unusable due to clutter, as it only understands closed/open)
7. Ability for anybody to submit a bug without opening github account 
(yes, I know it also produces the spam problem) and assigning bugs to 
people that don't have github account (we still can accept patches from 
those, can't we?).

8. Statistics

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.


I think it's way to generic statement. Some people choose github for 
doing some stuff would be more accurate. I don't think I can remember 
from the top of my head any major project that uses Github as their main 
bug tracker. Maybe they exist, but I certainly can't recall any.


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.


Why we must install it in a dark corner? Maybe we should ask for some 
help from people who are willing to contribute before we decide to scrap 
the whole thing.


Besides that, I am not sure I am feeling that comfortable with moving 
100% of the infrastructure of the PHP project to a platform wholly owned 
by Microsoft, and that's where things seem to be heading. I know 
Microsoft is almost not evil now, and it has no problem with PHP 
whatsoever, but things change, and who knows what would happen in 
another 5-10 years. I am not sure hard-binding the whole project to a 
single platform owned by a single company is that great. Due to the 
distributed nature of Git, the repository hosting is very low risk - it 
could be easily moved anywhere. But having the rest of the 
infrastructure in a single point of failure does not feel great. Once we 
move in there, it would be very hard to move out.


Maybe it's just my paranoia speaking, but I think this is also something 
we should be considering.

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

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

[PHP-DEV] Re: bugsnet cleanup

[Christoph M. Becker]

On 08.01.2017 at 14:31, Joe Watkins wrote:

> Leaving them open isn't helping anyone or anything, and if it overwhelms me
> to see that many, you can be pretty sure it has scared a bunch of people
> away.

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

>> Unmaintained bundled extensions should be considererd to be moved to PECL
>> as soon as possible (there is already a RFC draft[1] about this – I hope
>> this will proceed soon).
> 
> I'm not sure what you mean by unmaintained, anything bundled is maintained
> by virtue of the fact it is bundled ?

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

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

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

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

I'll think about it. :-)

-- 
Christoph M. Becker

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

[PHP-DEV] Re: bugsnet cleanup

[Joe Watkins]

Morning Christoph,

> Just wiping those under the carpet wouldn't be an improvement, in my
opinion.

Remember that the bugs won't go anywhere, they just won't present
themselves as important to new contributors, and old alike.

It's very overwhelming to see a list of five thousand things that may need
fixing, in reality most of the very old ones don't, and have no chance of
being addressed whatever.

If you're interested in looking through old FR's for stuff to RFC, then you
will still be able to do that.

We also have the option of adding a new status, such as "unresolved", so
that if you're so minded to go and look for old unresolved bugs, you can do
that with a simple search.

Leaving them open isn't helping anyone or anything, and if it overwhelms me
to see that many, you can be pretty sure it has scared a bunch of people
away.

> Instead it would be great if we had active maintainers

Agreed, but we do not, and there isn't much we can do to change that.

The fact is that the burden lies with us to maintain anything in php-src,
not whoever put it there. There are few exceptions, Derick does an
excellent job of maintaining date, there are a few people who work hard to
try to keep PDO and other extensions in shape (or they are emerging now as
maintainers).

> Unmaintained bundled extensions should be considererd to be moved to PECL
as soon as possible (there is already a RFC draft[1] about this – I hope
this will proceed soon).

I'm not sure what you mean by unmaintained, anything bundled is maintained
by virtue of the fact it is bundled ?

There's very few candidates for exclusion today. When I look at the list in
the RFC, it seems pretty obvious why some of them have no maintainer - the
underlying library is frozen in time (readline for example), there isn't
necessarily any real work to do, and nobody is obliged to satisfy
outstanding feature requests.

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

> Old tickets which can't be easily verified might best be handled by asking
whether the problem persists and setting the issue to "Feedback" (such as
#58167).

This takes the kind of manual labour that we just can't do, and are failing
hard at doing already ... It really would take a team, and we don't have
one.

I know there are a few people that sporadically work on bugs, yourself
included, and that's great.

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

My proposed actions are not about sweeping anything under any carpets, they
are about:

  * push people that have opened bugs with patches to go through github,
it's a more effective way of getting the job done
  * provide feedback to people that have been waiting for years on end for
some action
  * reduce the overall number of bugs so that new and old contributors are
not overwhelmed by the sheer number
  * make bugsnet a useful tool for finding things to fix in supported
versions of php - while it may seem that you can just search by version, in
reality this does not work, there are bugs that were opened for some old
version that still apply to 7

At some point, we need to admit that this is not manageable, and that
better tools exist for managing the influx of genuine bugs we do get. I
think actually we should consider closing down bugsnet entirely in the not
too distant future (maybe PHP8) and using the much better collaboration
tools provided by github.

Thanks for your valuable input, I look forward to seeing the bugs triage
RFC.

Cheers
Joe





On Sun, Jan 8, 2017 at 1:00 PM, Christoph M. Becker 
wrote:

> On 08.01.2017 at 07:46, Joe Watkins wrote:
>
> > Some of you may have noticed that a few of us have put considerable
> effort
> > into cleanup of pull requests on github, these are now manageable and I'm
> > quite confident that we will be able to merge pull requests in a timely
> > manner, and stay on top of it.
> >
> > When it comes to bugsnet, there are feature requests and bugs that have
> > been open for more than 10 years, and nobody has talked about them in
> about
> > as long, they may concern defunct versions of PHP, or removed extensions
> or
> > SAPIs: These numbers in the thousands.
> >
> > It's very difficult (impossible) to see a good reason for these to be
> open,
> > they are not useful at all.
> >
> > With normal support for 5 ended, now is the perfect time to cleanup
> > bugsnet. If we can get the numbers down to something manageable, we have
> a
> > reasonable expectation to stay on top of them.
> >
> > I think anyone that has been waiting a number of years for a response to
> a
> > feature request deserves to know that it is not reasonably happening, and
> > that there are better ways of trying to get a feature in than opening
> > yet-another-feature-request on bugsnet.
> >
> > I think any bug report opened against 4 and not updated is useless.
> >
> > I think anything 

[PHP-DEV] Re: bugsnet cleanup

[Christoph M. Becker]

On 08.01.2017 at 07:46, Joe Watkins wrote:

> Some of you may have noticed that a few of us have put considerable effort
> into cleanup of pull requests on github, these are now manageable and I'm
> quite confident that we will be able to merge pull requests in a timely
> manner, and stay on top of it.
> 
> When it comes to bugsnet, there are feature requests and bugs that have
> been open for more than 10 years, and nobody has talked about them in about
> as long, they may concern defunct versions of PHP, or removed extensions or
> SAPIs: These numbers in the thousands.
> 
> It's very difficult (impossible) to see a good reason for these to be open,
> they are not useful at all.
> 
> With normal support for 5 ended, now is the perfect time to cleanup
> bugsnet. If we can get the numbers down to something manageable, we have a
> reasonable expectation to stay on top of them.
> 
> I think anyone that has been waiting a number of years for a response to a
> feature request deserves to know that it is not reasonably happening, and
> that there are better ways of trying to get a feature in than opening
> yet-another-feature-request on bugsnet.
> 
> I think any bug report opened against 4 and not updated is useless.
> 
> I think anything with a patch attached targeting 5 is useless, regardless
> of age; they should be encouraged to open a pull request on github against
> a supported branch.
> 
> I'd like to hear what others think about cleaning up bugsnet, what criteria
> we might use for a mass cleanup.
> 
> After a mass cleanup, I/we will go in and start working through whatever is
> left, but 5k mostly irrelevant bugs is too much to ask, it would take me
> months and months to work through those, time that nobody has, or will ever
> have.

Thanks for bringing this up, Joe.  Generally, I fully agree that we
should clean up the bug tracker ASAP.

I'm not sure, though, if doing a general mass cleanup would really be
the best thing.  For instance, there are long-standing feature requests
which should already have been addressed, such as #32803 (I'm going to
start the RFC on this particular one soon) and #31784 (fontconfig is
already supported by external libgd, but not by our bundled one).  Also,
there are long-standing bug reports such as #34670 which ideally would
have been resolved in the meantime, but haven't.  Just wiping those
under the carpet wouldn't be an improvement, in my opinion.

Instead it would be great if we had active maintainers for all
extensions, and that these maintainers would concentrate on tickets
regarding their respective extensions (including relevant doc bugs).
PECL extensions which are not maintained anymore should be clearly
marked as such (on PECL and in the PHP manual), and all unresolved
issues could be marked as suspended.  Unmaintained bundled extensions
should be considererd to be moved to PECL as soon as possible (there is
already a RFC draft[1] about this – I hope this will proceed soon).

Old tickets which can't be easily verified might best be handled by
asking whether the problem persists and setting the issue to "Feeback"
(such as #58167).  That would still give users the possibility to
confirm that there's an unresolved problem, what appears to be
preferable to having a new follow-up ticket ("bug #12345 has been
closed, so I'm opening this ticket").

Also, we may consider building a triage team, similar to what had been
proposed for the pull requests[2], but never made it to a discission.
It seems to me that there a quite some developers who could assess a
certain issue, but might not be able to solve it by themselves with a
reasonable amount of effort.  Those more proficient with the engine or
the respective extension could concentrate on bugs labeled "verified"
and "analyzed".

[1] 
[2] 

-- 
Christoph M. Becker

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

[PHP-DEV] Re: bugsnet cleanup

[Maciej Sobaczewski]

Hi Joe,

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

Morning internals,

Some of you may have noticed that a few of us have put considerable effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.


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


When it comes to bugsnet, there are feature requests and bugs that have
been open for more than 10 years, and nobody has talked about them in about
as long, they may concern defunct versions of PHP, or removed extensions or
SAPIs: These numbers in the thousands.


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



It's very difficult (impossible) to see a good reason for these to be open,
they are not useful at all.

With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.

I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.

I think any bug report opened against 4 and not updated is useless.

I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.

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


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

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

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


After a mass cleanup, I/we will go in and start working through whatever is
left, but 5k mostly irrelevant bugs is too much to ask, it would take me
months and months to work through those, time that nobody has, or will ever
have.

Cheers
Joe



Thanks,
Maciej.


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