Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114305
MIME-Version: 1.0
References: <CAOwTYAtOti3+Tv9Cu5fK6bQ3tjAibRHUWOctnQFfGJyaoQYExw@mail.gmail.com>
 <de8c00e1-bf7d-a5d6-03a9-6aaf85960d1a@gmail.com>
In-Reply-To: <de8c00e1-bf7d-a5d6-03a9-6aaf85960d1a@gmail.com>
Date: Sun, 9 May 2021 09:47:50 +0200
Message-ID: <CAOwTYAuwq+6kz1w4LRwF8T4eK13TOG4qaKivpp03CCCfA1vfNA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>, 
	PHP Release Managers <release-managers@php.net>
Content-Type: multipart/alternative; boundary="000000000000672a9f05c1e0e1f5"
Subject: Re: Bugsnet
From: krakjoe@gmail.com (Joe Watkins)

--000000000000672a9f05c1e0e1f5
Content-Type: text/plain; charset="UTF-8"

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 <smalyshev@gmail.com> 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 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
>

--000000000000672a9f05c1e0e1f5--