Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114303
To: Joe Watkins <krakjoe@php.net>, PHP internals <internals@lists.php.net>,
 PHP Release Managers <release-managers@php.net>
References: <CAOwTYAtOti3+Tv9Cu5fK6bQ3tjAibRHUWOctnQFfGJyaoQYExw@mail.gmail.com>
Message-ID: <de8c00e1-bf7d-a5d6-03a9-6aaf85960d1a@gmail.com>
Date: Sun, 9 May 2021 00:33:08 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
 Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <CAOwTYAtOti3+Tv9Cu5fK6bQ3tjAibRHUWOctnQFfGJyaoQYExw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: Bugsnet
From: smalyshev@gmail.com (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
smalyshev@gmail.com