> On Jan 4, 2017, at 5: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).
This seems sensible, yes. > > 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 still strongly disagree with you here. You've described the first thing *you* do when working on a ticket, but that's not the first thing *I* do. My first step is to decide whether or not a care about a ticket, roughly like this: - Read ticket title. If it's not about my area, stop. - If the ticket is obviously a bug (panic, core lint error): * Check the version reported. If the version is old and I'm squeezed for time at the moment, stop. * Try to reproduce at the version reported. If I can't, report this on the ticket. * If HEAD is around on my machine and I'm sufficiently interested, try to repro on HEAD. Report my findings. - If the ticket is not obviously a bug (complicated type-level shenanigans that is either accepted or rejected): * Think Hard about whether behavior is expected or not and report accordingly. * If behavior is indeed a bug, continue with the steps outlined above. Note that version numbers play a key role in the triage process! If we had a bot that could try to repro every reported bug on HEAD and could report its findings, I would find the need for a version number less pressing. But until then, it's very very helpful. > > 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. Indeed. And I think using a tag list instead of the current keywords/component interface would be an improvement. At the same time, we need to identify workflows that go well with Trac but which might be disrupted in the changeover. I'm not arguing that any disrupted workflows are a deal-breaker, but we need to know what they are. Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
