wt., 7 sie 2018 o 22:10 Sara Golemon <pollita@php.net> napisał(a):
>
> On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
> <t.motylewski@gmail.com> wrote:
> That's a bit harsh, but I get your point, it's a getting to be... long
> in the tooth, shall we say.
Sorry for that, got too passionate about PHP ;)
> At a start (non-exhaustive):
> 1. Need for integration with PHP's dev login database (x@php.net people)
Do you have some auth with API already in place (ldap, oauth, ...)?
> 2. Ability to import and index ALL existing bug reports. You may have
> trouble parsing it, but it's most certainly of value to those of us
> fixing these bugs.
> 3. Support for existing bug reports still being editable by their
> original posters (requiring them to create a new account tied to their
> original email is acceptable)
> 4. Support for private bugs only visible to a small subset of devs (
> https://github.com/php/web-bugs/blob/master/include/trusted-devs.php
> ). Security vulnerability reports shouldn't double as zero-day
> announcements.
2,3,4 require work of course, but is nothing unexpected when migrating
issue tracker.
> Beyond that there are some unexpected requirements. For example, did
> you ever wonder why php.net doesn't use any frameworks? Partly it's
> because of its age, but it's also because the minute we do, we
> implicitly endorse that framework and that upsets the balance of the
> ecosystem. We don't want one framework or another to win by default,
> we want the best solutions to rise up and excel in their ideal space
> on their merits (as much as that's possible). As a result, all of
> PHP's website code is artisanal, hand-written, and in some areas, a
> bit crap. That same guideline would certainly apply to any
> off-the-shelf bug tracker. Does this make replacing bugs.php.net
> 100,000% more difficult? Yes, yes it does. However, Cæsar's wife must
> be beyond reproach.
I would look not for a framework to build new issue tracker on top, but rather
an out of the box products, so not every framework is a candidate at all.
Do I read you correctly, that the new issue tracker has to be written in PHP?
What about a SAAS platforms like github, gitlab and so? Can they also
be considered?
Imagine you will implement a login to bugs.php.net consuming github or
gmail oauth,
will you then also write oauth library yourself, or use any existing
one, from the
PHP community?
> What this all ends up meaning is that the best way forward is small
> (read: reviewable), incremental improvements to the bug tracker we
> have.
I'm not against it, however I imagine that the PHP maintainers have
better things
to do than to build yet another bug tracker.
> > - the UI is terrible (not useful, confusing, misleading)
> UI is harsh and a bit 90s in styling, but I have a hard time agreeing
> with the rest of that statement. What is confusing to you?
I'm sure it's clear for you, as you're used to the system and know the
internals.
However try putting a regular user in front of it and ask him to do
some action ;)
e.g.
- how to get back to the filtered list, from single issue?
- What filters are enabled on the list (seems you have to brain-parse
url to check it)?
- comment form being on top, far away from the last comments on the
longer threads
- "Developer" tab is useful only for php.net users, so it should be
visible only when they log in,
- labels of the input fields are not much helpful without additional
explanation/help,
like "Return bugs assigned to" - what should I put inside? email address, nick?
"Return bugs updated" - will selecting 90 return me issues older than
90 days or younger?
- and the winner of the confusion context - the comment form - what should I
do to both send a comment and be notified? should I first subscribe
and then comment,
or is subscription done automatically when you submit a comment?
"Subscribe to this entry" - does "entry" means issue in this case? ;)
> > - data quality is low (many duplicated reports, lot of old reports
> >
> In fairness, you'll find this in every bug system for any project with
> even moderate popularity.
yes an no, it's true that every bigger project has the same problem,
but the difference is in the scale.
I did a quick grasp and I see more than 1k issues which were not
updated since some years and were reported to not maintained versions.
My argument is that if regular logged in users were able to e.g.
set/add newer affected PHP version,
os system (but please a list, not an input), relate issues together
(related, duplicated),
then it will be much easier for PHP maintainers to close old,
unrelated or duplicated issues.
Many other opensource systems managed to gather people who are not in
the maintainer group/core team,
but who has higher permissions (like edit issue, change status, etc).
In other words people who you trust enough to be able to clean issue
tracker a bit.
> > - the tool blocks community in helping managing the issue list and triaging bugs
> Citation needed.
Here I am ;) I'm involved in many OSS communities, like TYPO3 (I'm a
core dev there),
Magento, etc. I see PHP issue tracker being the least pleasant to use.
One recent example - when investigating security issues related to
phar archives before our last
security release for TYPO3 I spend some hours using bugs.php.net,
reading issues, trying to find sth related. I saw many issues which
were duplicated,
or at last very related but there was no way for me to connect them -
thus helping
managing the issue queue.
I'm pretty sure if you ask regular PHP developers, you will hear
similar opinions.
People are used to features and ease of use provided by e.g.
github/gitlab/bitbucket....
> > - Its not possible to log in, be notified when sth change on issues
> >
> Incorrect. Any issue you comment on will email you (assuming you've
> provided a valid email address) on any change.
> I'll grant that you shouldn't need to put your email address in a
> public place (the obfuscation is a joke) just to subscribe to updates,
> but subscribing is possible.
Interesting. I dont recall getting an any email from bugs.php.net, and
I'm pretty sure
I was involved in some issues with different emails. But maybe they
were not modified?
> Is our hypothetical volunteer somewhere between "wanting to help" and
> "not wanting to get a php.net account"? Because that's the user who's
> unable to link issues.
Is it possible to register on php.net and get an account? Where? How?
> Also, comments make for lovely links. The bug ID urls are 100%
> restful permalinks.
I would expect that putting an issue number (or the full link) in the comment
would also result in listing the issue in the "Related reports" tab.
> > how can I get it back once I forgot?
> >
> That, funnily, is a bug. There should be a link to
> https://bugs.php.net/bug-pwd-finder.php?id=$bugid next to the password
> field. I'll fix that in a moment.
thanks :)
> > - The "Same OS" stats are not really helpful, it doesn't even help to
> > know whether it's windows only issue or also linux related, it's not
> > really possible to filter issues related to some system
> >
> It absolutely does help to know if it's OS specific. That points to
> cause, and ultimately solution.
Sorry, I was not clear enough. I agree that the field is important.
I wanted to say that the data quality we currently have
in bugs.php.net for the OS field is low (because of issues described above).
As a user how can I filter issues only related to linux?
> ((Yes, I know, triage
> and maintenance of data is a side-effect of the usability of the
> tool.))
That's what I'm trying to say ;)
> > - there are tons of stale issues even from over 10 years ago. With
> > better issue tracker people from community would be able to help
> > triaging these bugs, confirming them, setting correct statuses,
> > finding duplicates and so
> >
> Are you suggesting that arbitrary users be allowed to alter bug report
> status without authentication? If you think the data is worthless
> now, you'll love what happens when anyone can edit anything without
> limitation.
No, please see my comments above.
1. we need login, and everything even comments have to be made by logged in user
2. authenticated users should be able to set basic things like issue relations
3. there might be a group of user with higher rights (but not as high
as maintainers)
> Many of the above can be fixed, and the entire site is in PHP and on
> github. I encourage you to offer pull requests!
Where? How can I setup a local dev environment with current issue tracker?
Is there a demo/stripped db dump available?
