Trac to Phabricator (Maniphest) migration prototype
matthewtpickering at gmail.com
Wed Jan 4 10:20:51 UTC 2017
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!
On Wed, Jan 4, 2017 at 10:18 AM, Matthew Pickering
<matthewtpickering at 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,
> 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.
> 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 <ezyang at 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
>> 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
>> 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
>> Well, this is something we can fix with a little CSS :)
>>> Thanks for your comments.
>>> On Tue, Jan 3, 2017 at 5:21 PM, Edward Z. Yang <ezyang at 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?
More information about the ghc-devs