I should have looked more closely at the implementation.. the component field was already preserved. There is a bug where it is not set properly if it was set by the ticket reporter. I will look into this problem this evening!
Matt On Wed, Jan 4, 2017 at 10:18 AM, Matthew Pickering <matthewtpicker...@gmail.com> wrote: > I am persuaded that component is useful. Richard makes the point that > there is a murky divide between component and keywords. This is right > and it indicates that we should keep the component field but also > homogenise it was the keywords (in the form of projects). > > I have included which fields are used frequently in the footer of this > message. > > The arguments for version are not convincing. The first thing you do > when working on a ticket anyway is to try and reproduce the bug with a > test case in HEAD. The date a ticket reported is as good an indicator > of version. > > I also noted that I neglected to update the dateUpdated field for > tickets so queries by date last modified do not currently work and > some dates may appear strange when searching. > > Edward: There is support for bucketing by project as well. See this > query for example, > http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/maniphest/query/AnBbna53Q.ue/#R > > In these discussions we should remember that phabricator is not trac. > I am not trying to exactly recreate the trac experience because > otherwise we might as well carry on using trac. > > Matt > > newvalue | count | data last used > > -------------------------+-------+------------------ > Core Libraries | 171 | 1467895032829170 > Compiler (Type checker) | 162 | 1473084454218219 > Runtime System | 128 | 1465462467207643 > GHCi | 78 | 1469178319691539 > Build System | 67 | 1466005572342115 > libraries/base | 63 | 1434353266824396 > Template Haskell | 60 | 1471813543330680 > Compiler | 57 | 1454111515909737 > Compiler (Parser) | 48 | 1469089960346131 > libraries (other) | 43 | 1426680041417003 > Documentation | 34 | 1469109265405752 > Runtime System (Linker) | 31 | 1465457535216398 > Profiling | 27 | 1464370392337006 > Compiler (NCG) | 24 | 1464454221111344 > Driver | 23 | 1464988993920936 > Compiler (Linking) | 20 | 1453415934718049 > Package system | 19 | 1445379269305504 > Test Suite | 19 | 1466101320438273 > libraries/process | 17 | 1380279285602376 > Compiler (LLVM) | 17 | 1453643706521552 > Trac & Git | 13 | 1417192612294646 > Compiler (CodeGen) | 12 | 1466888486602141 > Code Coverage | 9 | 1463929919796252 > Compiler (FFI) | 9 | 1438109440242842 > libraries/unix | 8 | 1393611940333801 > Data Parallel Haskell | 8 | 1427089471985001 > None | 8 | 1457637409612864 > hsc2hs | 5 | 1433929228414856 > libraries/network | 5 | 1225140383000000 > libraries/random | 4 | 1404824781090514 > libraries/directory | 4 | 1355926496000000 > External Core | 4 | 1365855698000000 > libraries/pretty | 4 | 1321743759000000 > ghc-pkg | 4 | 1447954686599857 > GHC API | 3 | 1463577929270933 > libraries/HGL | 3 | 1214961444000000 > Prelude | 2 | 1313617037000000 > libraries/haskell98 | 1 | 1186695581000000 > libraries (old-time) | 1 | 1215426256000000 > Visual Haskell | 1 | 1166430307000000 > NoFib benchmark suite | 1 | 1405260335339305 > > On Wed, Jan 4, 2017 at 4:34 AM, Edward Z. Yang <ezy...@mit.edu> wrote: >> Excerpts from Matthew Pickering's message of 2017-01-03 23:32:42 +0000: >>> The version field is not very useful as there are only two active >>> branches at once. Instead we want a project which marks tickets which >>> apply to the 8.0.2 branch for example. Tickets which refer to ancient >>> versions of GHC should be closed if they can't be reproduced with >>> HEAD. It is also not used very often, only updated on about 600 >>> tickets. >> >> Echoing Richard's comment, it's a helpful reminder to the reporter >> to say what version of GHC the bug was on. If it's old, the first >> thing to do is check if it still fails in HEAD. >> >>> I'm also skeptical about how useful the component field is. I've never >>> personally used it and it is not accurate for the majority of tickets. >>> If someone disagrees then please say but it is really not used very >>> much. >> >> I think that there is a substantial subset of tickets that have a good >> "component" characterization. I have historically found "Runtime >> system", "Linker", "Build system", "Profiling" and a number of others >> very useful. Yes, a lot of tickets get dumped in "Compiler", but many >> have very good categorization! >> >>> 2. This is a legitimate point. I will say in response that the >>> majority of triaging is done by those who regularly use the bug >>> tracker. These people will know the correct tags to use. There are >>> occasionally people who submit tickets and ask questions about what to >>> fill in these fields or fill them in incorrectly. Removing them for a >>> uniform system is advantageous in my opinion. >> >> I am a "regular user" of Cabal's GitHub bug tracker, and I find it >> difficult to remember to apply all of the tags that I'm "supposed" to >> for any given ticket. It got better when I reorged all the tags >> to give them a prefix for the "category" they were in, but I still >> have to scroll through the list that contains ALL THE TAGS when >> really I just want to select one per category. For example, priority >> in GH is a complete lost cause because none of the display mechanisms >> take priority into account. >> >> Another benefit of tags by category is in tabular views, you can ask >> to group things by category, or priority, etc. Tag based systems rarely >> have this kind of UI. >> >>> I agree with you about the default layout. I would also like a more >>> compact view but I feel this style is the prevailing modern web dev >>> trend. >> >> Well, this is something we can fix with a little CSS :) >> >> Edward >> >>> Thanks for your comments. >>> >>> Matt >>> >>> On Tue, Jan 3, 2017 at 5:21 PM, Edward Z. Yang <ezy...@mit.edu> wrote: >>> > Hi Matthew, >>> > >>> > Thanks for doing the work for setting up this prototype, it definitely >>> > helps in making an informed decision about the switch. >>> > >>> > Some comments: >>> > >>> > 1. In your original email, you stated that many of the custom fields >>> > were going to be replaced with Phabricator "projects" (their >>> > equivalent of tags). First, I noticed a little trouble where >>> > some fields were just completely lost. Compare: >>> > >>> > http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T8095 >>> > https://ghc.haskell.org/trac/ghc/ticket/8095 >>> > >>> > AFAICT, we lost version the bug was found in, >>> > architecture, component. I hope we can keep these details >>> > in the real migration! Also related tickets doesn't seem >>> > to be working (see example above); migration problem? _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
