Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97850 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90592 invoked from network); 18 Jan 2017 07:37:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jan 2017 07:37:42 -0000 X-Host-Fingerprint: 109.241.90.225 109241090225.olsztyn.vectranet.pl Received: from [109.241.90.225] ([109.241.90.225:12522] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D9/44-00729-54B1F785 for ; Wed, 18 Jan 2017 02:37:42 -0500 Message-ID: To: internals@lists.php.net References: <47370a17-d428-b30d-183b-c1ec96d47872@gmail.com> <8307a455-1f57-b289-74cb-71c3a0410c92@gmail.com> <4d79d06b-671e-02c8-0e8d-d019ff57b7e0@gmail.com> <53556e09-af3a-e5b1-5c82-6c974742c407@gmx.de> <13d379ad-cf24-6ca2-b8b9-2cd7281114fa@heigl.org> Date: Wed, 18 Jan 2017 08:37:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 170117-2, 17.01.2017), Outbound message X-Antivirus-Status: Clean X-Posted-By: 109.241.90.225 Subject: Re: [PHP-DEV] bugsnet cleanup From: sobak@php.net (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.