W dniu 17.01.2017 o 18:47, Niklas Keller pisze:
2017-01-17 18:22 GMT+01:00 Andreas Heigl <andr...@heigl.org>:
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
