In response to no# 2, I was looking at this my self since I think separate fields would definitely be useful. It seems you can customize the form design on phabricrator. <div><br></div><div>I think it would definitely be worth it to make a new form layout resembling the layout of track. I don't know how it stores it but presumably this would also improve the searching allowing you to filter on specific fields instead of just tags. </div><div><br></div><div>Have you looked into this already Matt? <br><br><div class="gmail_quote"><div dir="ltr">On Tue, 3 Jan 2017, 23:33 Matthew Pickering, <<a href="mailto:matthewtpickering@gmail.com">matthewtpickering@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good comments Edward. I think the answers to all three of your points<br class="gmail_msg">
will be insightful.<br class="gmail_msg">
<br class="gmail_msg">
1. As for why it appears some information from the ticket is missing.<br class="gmail_msg">
<br class="gmail_msg">
The version field is not very useful as there are only two active<br class="gmail_msg">
branches at once. Instead we want a project which marks tickets which<br class="gmail_msg">
apply to the 8.0.2 branch for example. Tickets which refer to ancient<br class="gmail_msg">
versions of GHC should be closed if they can't be reproduced with<br class="gmail_msg">
HEAD. It is also not used very often, only updated on about 600<br class="gmail_msg">
tickets.<br class="gmail_msg">
<br class="gmail_msg">
A tag for the architecture field is only added if the architecture is<br class="gmail_msg">
set to something other than the default. The ticket you linked had the<br class="gmail_msg">
default value and in fact, architecture was irrelevant to the ticket<br class="gmail_msg">
as it was about the type checker so it could be argued including this<br class="gmail_msg">
option is confusing to the reporter.<br class="gmail_msg">
<br class="gmail_msg">
I'm also skeptical about how useful the component field is. I've never<br class="gmail_msg">
personally used it and it is not accurate for the majority of tickets.<br class="gmail_msg">
If someone disagrees then please say but it is really not used very<br class="gmail_msg">
much.<br class="gmail_msg">
<br class="gmail_msg">
Finally, the related tickets look slightly off.<br class="gmail_msg">
This is a reoccurring problem with trac, there is no validation for<br class="gmail_msg">
any of the text fields. The parser I wrote assumed that tickets<br class="gmail_msg">
started with a # but in this example the first related ticket<br class="gmail_msg">
initially was hashless. There are many examples like this which I have<br class="gmail_msg">
come across. In this case I think I can relax it to search for any<br class="gmail_msg">
contiguous set of numbers and recover the correct information.<br class="gmail_msg">
<br class="gmail_msg">
The dump of the database which I had is about two months old which<br class="gmail_msg">
explains why the most recent changes are not included.<br class="gmail_msg">
<br class="gmail_msg">
Here is how often each field has been updated.<br class="gmail_msg">
<br class="gmail_msg">
field | count<br class="gmail_msg">
--------------+-------<br class="gmail_msg">
_comment0 | 1839<br class="gmail_msg">
_comment1 | 364<br class="gmail_msg">
_comment10 | 1<br class="gmail_msg">
_comment11 | 1<br class="gmail_msg">
_comment12 | 1<br class="gmail_msg">
_comment13 | 1<br class="gmail_msg">
_comment14 | 1<br class="gmail_msg">
_comment15 | 1<br class="gmail_msg">
_comment16 | 1<br class="gmail_msg">
_comment2 | 123<br class="gmail_msg">
_comment3 | 53<br class="gmail_msg">
_comment4 | 23<br class="gmail_msg">
_comment5 | 13<br class="gmail_msg">
_comment6 | 4<br class="gmail_msg">
_comment7 | 4<br class="gmail_msg">
_comment8 | 3<br class="gmail_msg">
_comment9 | 1<br class="gmail_msg">
architecture | 2025<br class="gmail_msg">
blockedby | 1103<br class="gmail_msg">
blocking | 1112<br class="gmail_msg">
cc | 5358<br class="gmail_msg">
comment | 75967<br class="gmail_msg">
component | 1217<br class="gmail_msg">
description | 1919<br class="gmail_msg">
differential | 2410<br class="gmail_msg">
difficulty | 4968<br class="gmail_msg">
failure | 1427<br class="gmail_msg">
keywords | 833<br class="gmail_msg">
milestone | 13695<br class="gmail_msg">
os | 1964<br class="gmail_msg">
owner | 4870<br class="gmail_msg">
patch | 26<br class="gmail_msg">
priority | 2495<br class="gmail_msg">
related | 1869<br class="gmail_msg">
reporter | 7<br class="gmail_msg">
resolution | 10446<br class="gmail_msg">
severity | 83<br class="gmail_msg">
status | 14612<br class="gmail_msg">
summary | 827<br class="gmail_msg">
testcase | 2386<br class="gmail_msg">
type | 811<br class="gmail_msg">
version | 687<br class="gmail_msg">
wikipage | 873<br class="gmail_msg">
<br class="gmail_msg">
2. This is a legitimate point. I will say in response that the<br class="gmail_msg">
majority of triaging is done by those who regularly use the bug<br class="gmail_msg">
tracker. These people will know the correct tags to use. There are<br class="gmail_msg">
occasionally people who submit tickets and ask questions about what to<br class="gmail_msg">
fill in these fields or fill them in incorrectly. Removing them for a<br class="gmail_msg">
uniform system is advantageous in my opinion.<br class="gmail_msg">
<br class="gmail_msg">
3. Here is how the search works. It is context sensitive, if you<br class="gmail_msg">
search from the home page then you search everything. If you search<br class="gmail_msg">
after clicking on "maniphest" to enter the maniphest application it<br class="gmail_msg">
will only search tickets.<br class="gmail_msg">
<br class="gmail_msg">
There is a similar advanced search for Maniphest -<br class="gmail_msg">
<a href="http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/maniphest/query/advanced/" rel="noreferrer" class="gmail_msg" target="_blank">http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/maniphest/query/advanced/</a><br class="gmail_msg">
Using this you can sort by priority and then by ticket number. Here is<br class="gmail_msg">
an example searching the tickets with the PatternSynonyms tag -<br class="gmail_msg">
<a href="http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/maniphest/query/WjCq6bD27idM/#R" rel="noreferrer" class="gmail_msg" target="_blank">http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/maniphest/query/WjCq6bD27idM/#R</a><br class="gmail_msg">
<br class="gmail_msg">
I agree with you about the default layout. I would also like a more<br class="gmail_msg">
compact view but I feel this style is the prevailing modern web dev<br class="gmail_msg">
trend.<br class="gmail_msg">
<br class="gmail_msg">
Thanks for your comments.<br class="gmail_msg">
<br class="gmail_msg">
Matt<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On Tue, Jan 3, 2017 at 5:21 PM, Edward Z. Yang <<a href="mailto:ezyang@mit.edu" class="gmail_msg" target="_blank">ezyang@mit.edu</a>> wrote:<br class="gmail_msg">
> Hi Matthew,<br class="gmail_msg">
><br class="gmail_msg">
> Thanks for doing the work for setting up this prototype, it definitely<br class="gmail_msg">
> helps in making an informed decision about the switch.<br class="gmail_msg">
><br class="gmail_msg">
> Some comments:<br class="gmail_msg">
><br class="gmail_msg">
> 1. In your original email, you stated that many of the custom fields<br class="gmail_msg">
> were going to be replaced with Phabricator "projects" (their<br class="gmail_msg">
> equivalent of tags). First, I noticed a little trouble where<br class="gmail_msg">
> some fields were just completely lost. Compare:<br class="gmail_msg">
><br class="gmail_msg">
> <a href="http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T8095" rel="noreferrer" class="gmail_msg" target="_blank">http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T8095</a><br class="gmail_msg">
> <a href="https://ghc.haskell.org/trac/ghc/ticket/8095" rel="noreferrer" class="gmail_msg" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/8095</a><br class="gmail_msg">
><br class="gmail_msg">
> AFAICT, we lost version the bug was found in,<br class="gmail_msg">
> architecture, component. I hope we can keep these details<br class="gmail_msg">
> in the real migration! Also related tickets doesn't seem<br class="gmail_msg">
> to be working (see example above); migration problem?<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
ghc-devs mailing list<br class="gmail_msg">
<a href="mailto:ghc-devs@haskell.org" class="gmail_msg" target="_blank">ghc-devs@haskell.org</a><br class="gmail_msg">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" class="gmail_msg" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br class="gmail_msg">
</blockquote></div></div>