GHC 8.2.1 tree freeze timing

[Ben Gamari]

tl;dr. The feature freeze for GHC 8.2 will happen on 30 January 2016.
   Get any patches you'd like to see in 8.2 up on Phabricator soon!


Hello everyone,

GHC 8.2.1 is quickly approaching. Our plan is to do a release candidate
in February, so we would like to have the tree sorted out by the end of
this month. Consequently, I would like to set a general feature freeze
for 30 Janary 2016. After the freeze I will be much less likely to
accept larger patches; ideally all work post-freeze should be in the
name of preparing the tree for cutting the ghc-8.2 branch.

If you are concerned that your work isn't positioned to meet this freeze
date then please speak to me so we can make appropriate arrangements.

Happy hacking!

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC 8.2.1 tree freeze timing

[Ben Gamari]

Hello everyone,

GHC 8.2.1 is quickly approaching. Our plan is to do a release candidate
in February, so we would like to have the tree sorted out by the end of
this month. Consequently, I would like to set a general feature freeze
for 30 Janary 2016.

If you are concerned that your work isn't positioned to meet this freeze
date then please speak to me so we can make appropriate arrangements.

Happy hacking!

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Navigating GHC proposals

[Richard Eisenberg]

> On Jan 9, 2017, at 11:03 AM, Simon Marlow  wrote:
> 
> The constraint-vs-type proposal seems a little bit weird in that it actually 
> has a branch in the ghc-proposals repository itself, rather than being a pull 
> request from a fork in @goldfire's account.  Richard, was that intentional?

I like to use GitHub's edit-in-place feature. Previously, I could write my 
proposal and then GitHub would prepare the pull request by automatically 
forking the repository (if I hadn't already), making a branch in my own fork, 
and then posting the PR. Now, however, because I have commit access to 
ghc-proposals, it only allows me to automatically create a branch at 
ghc-proposals/ghc-proposals, not goldfirere/ghc-proposals. Was this choice 
intentional? Not quite -- I didn't originally want to do it this way. But I did 
know what I was doing when I clicked "go". In retrospect, if all the committee 
members wrote proposals the way I did, it would clutter ghc-proposals. I'll 
avoid this in the future, now that I know GitHub won't automatically do what I 
want when I have commit access.

And I've added a link from the rendered version back to the PR. I do think this 
is a good practice but it must be manually done.

Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Navigating GHC proposals

[Simon Peyton Jones via ghc-devs]

That is amazingly indirect.  Oh well.

Simon

From: Simon Marlow [mailto:marlo...@gmail.com]
Sent: 09 January 2017 16:55
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org; Richard Eisenberg 
Subject: Re: Navigating GHC proposals

Well, you can go to the history of the file, and from there to the first commit 
("Rename proposal file"), and from there you'll see a link to the pull request 
in the blue box next to the name of the branch (the link looks like "#32" in 
this case).

But really, I wouldn't recommend sending the rendered link to someone, send the 
link to the pull request.



On 9 January 2017 at 16:05, Simon Peyton Jones 
> wrote:
I don't think there is a way to go from the rendered proposal to the pull 
request, other than the "back" button in your browser.

Seriously?  But the rendered proposal is the useful link to send to people.  
There _must_ be a way, even if its indirect.

Simon

From: Simon Marlow [mailto:marlo...@gmail.com]
Sent: 09 January 2017 16:03
To: Simon Peyton Jones >
Cc: ghc-devs@haskell.org; Richard Eisenberg 
>
Subject: Re: Navigating GHC proposals

I don't think there is a way to go from the rendered proposal to the pull 
request, other than the "back" button in your browser.

The constraint-vs-type proposal seems a little bit weird in that it actually 
has a branch in the ghc-proposals repository itself, rather than being a pull 
request from a fork in @goldfire's account.  Richard, was that intentional?

On 9 January 2017 at 13:55, Simon Peyton Jones via ghc-devs 
> wrote:
Once I am looking the rendered form of a GHC proposal, eg
https://github.com/ghc-proposals/ghc-proposals/blob/rae/constraint-vs-type/proposals/-constraint-vs-type.rst
how can I find my way to the “conversation” for that proposal, so I can comment 
on it?
https://github.com/ghc-proposals/ghc-proposals/pull/32

Once more, I am lost in a maze of twisty little Githup passages.  I clearly 
have not yet internalised an accurate model of what Github is thinking
Thanks
Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Navigating GHC proposals

[Joachim Breitner]

Hi,

Am Montag, den 09.01.2017, 16:03 + schrieb Simon Marlow:
> I don't think there is a way to go from the rendered proposal to the
> pull request, other than the "back" button in your browser.

nothing stops the author to add a link to the discussion to the file,
as I did in my proposal (first line):
https://github.com/nomeata/ghc-proposals/blob/patch-1/proposals/-forced-class-instantiation.rst

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: nofib on Shake

[Joachim Breitner]

Hi,

Am Montag, den 09.01.2017, 19:48 + schrieb Michal Terepeta:
> On Sun, Jan 8, 2017 at 10:56 PM Joachim Breitner  
> wrote:
> > Hi,
> >
> > Am Sonntag, den 08.01.2017, 13:45 -0500 schrieb Ben Gamari:
> > > > We could also create a cabal and stack files for `nofib-analyse` (making
> > > > it possible to use some libraries for it).
> > > >
> > > This would be great. This would allow me to drop a submodule from my own
> > > performance monitoring tool.
> >
> > Exists since last April:
> > http://hackage.haskell.org/package/nofib-analyse
> >
> > Only the binary so far, though, but good enough for
> > "cabal install nofib-analyse".
> 
> Oh, interesting! But now I'm a bit confused - what's the relationship
> > between https://github.com/nomeata/nofib-analyse and
> https://git.haskell.org/nofib.git, e.g., is the github repo the
> upstream for nofib-anaylse and the haskell.org one for the other parts
> of nofib? Or is the github one just a mirror and all patches should go
> to haskell.org repo?

my repo occasionally pulls in the nofib-analyse directory from the
haskell.org nofib repo; see for example this commit (especially its
message):
https://github.com/nomeata/nofib-analyse/commit/8225e0dd84c3c31cd156d10df75ea47ea29eda87

So yes, patches go to the haskell.org nofib repo (or Phab or whatever).

Greetings,
Joachim
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: nofib on Shake

[Michal Terepeta]

On Sun, Jan 8, 2017 at 10:56 PM Joachim Breitner 
wrote:
> Hi,
>
> Am Sonntag, den 08.01.2017, 13:45 -0500 schrieb Ben Gamari:
> > > We could also create a cabal and stack files for `nofib-analyse`
(making
> > > it possible to use some libraries for it).
> > >
> > This would be great. This would allow me to drop a submodule from my own
> > performance monitoring tool.
>
> Exists since last April:
> http://hackage.haskell.org/package/nofib-analyse
>
> Only the binary so far, though, but good enough for
> "cabal install nofib-analyse".

Oh, interesting! But now I'm a bit confused - what's the relationship
between https://github.com/nomeata/nofib-analyse and
https://git.haskell.org/nofib.git, e.g., is the github repo the
upstream for nofib-anaylse and the haskell.org one for the other parts
of nofib? Or is the github one just a mirror and all patches should go
to haskell.org repo?

Thanks,
Michal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: nofib on Shake

[Michal Terepeta]

> On Sun, Jan 8, 2017 at 7:45 PM Ben Gamari  wrote:
> Michal Terepeta  writes:
>
> > Hi all,
> >
> > While looking at nofib, I've found a blog post from Neil Mitchell [1],
> > which describes a Shake build system for nofib. The comments mentioned
> > that this should get merged, but it seems that nothing actually
happened?
> > Is there some fundamental reason for that?
> >
> Indeed there is no fundamental reason and I think it would be great to
> make nofib a bit easier to run and modify.

Ok, cool. I'll have a look at using Neil's code and see if it needs
any updating or if something is missing.

> However, I think we should be careful to maintain some degree of
> compatibility. One of the nice properties of nofib is that it can be run
> against a wide range of compiler versions. It would be ashame if, for
> instance, Joachim's gipeda had to do different things to extract
> performance metrics from logs produced by logs pre- and post-Shake
> nofibs.

Thanks for mentioning this! I don't have any concrete plans to change
that at the moment, but I was thinking that in the future it'd be nice
if the results were, e.g., a simple csv file, instead of a log
containing all the stdout/stderr (i.e., it currently contains the
results, any warnings from GHC, output from `Debug.Trace.trace`,
etc.)
Anyway, that's probably further down the road, so before doing
anything, I'll likely send an email to ghc-devs so that we can discuss
this.


Cheers,
Michal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Navigating GHC proposals

[Simon Marlow]

Well, you can go to the history of the file, and from there to the first
commit ("Rename proposal file"), and from there you'll see a link to the
pull request in the blue box next to the name of the branch (the link looks
like "#32" in this case).

But really, I wouldn't recommend sending the rendered link to someone, send
the link to the pull request.



On 9 January 2017 at 16:05, Simon Peyton Jones 
wrote:

> I don't think there is a way to go from the rendered proposal to the pull
> request, other than the "back" button in your browser.
>
>
>
> Seriously?  But the rendered proposal is the useful link to send to
> people.  There _*must_ *be a way, even if its indirect.
>
>
>
> Simon
>
>
>
> *From:* Simon Marlow [mailto:marlo...@gmail.com]
> *Sent:* 09 January 2017 16:03
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs@haskell.org; Richard Eisenberg 
> *Subject:* Re: Navigating GHC proposals
>
>
>
> I don't think there is a way to go from the rendered proposal to the pull
> request, other than the "back" button in your browser.
>
>
>
> The constraint-vs-type proposal seems a little bit weird in that it
> actually has a branch in the ghc-proposals repository itself, rather than
> being a pull request from a fork in @goldfire's account.  Richard, was that
> intentional?
>
>
>
> On 9 January 2017 at 13:55, Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> Once I am looking the rendered form of a GHC proposal, eg
>
> https://github.com/ghc-proposals/ghc-proposals/blob/
> rae/constraint-vs-type/proposals/-constraint-vs-type.rst
> 
>
> how can I find my way to the “conversation” for that proposal, so I can
> comment on it?
>
> https://github.com/ghc-proposals/ghc-proposals/pull/32
> 
>
>
>
> Once more, I am lost in a maze of twisty little Githup passages.  I
> clearly have not yet internalised an accurate model of what Github is
> thinking
>
> Thanks
>
> Simon
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Debugging GHC with GHCi

[Simon Marlow]

On 9 January 2017 at 04:51, Ben Gamari  wrote:

> Thomas Jakway  writes:
>
> > I want to be able to load certain GHC modules in interpreted mode in
> > ghci so I can set breakpoints in them.  I have tests in the testsuite
> > that are compiled by inplace/bin/ghc-stage2 with -package ghc.  I can
> > load the tests with ghc-stage2 --interactive -package ghc but since ghc
> > is compiled I can only set breakpoints in the tests themselves.  Loading
> > the relevant files by passing them as absolute paths to :l loads them
> > but ghci doesn't stop at the breakpoints placed in them (I'm guessing
> > because ghci doesn't realize that the module I just loaded is meant to
> > replace the compiled version in -package ghc).
> >
> > So if I use
> >
> > inplace/bin/ghc-stage2 --interactive -package ghc mytest.hs
> > then
> > :l abs/path/to/AsmCodeGen.hs
> >
> > and set breakpoints, nothing happens.
> >
> Many of us would love to be able to load GHC into GHCi. Unfortunately,
> we aren't currently in a position where this is possible. The only thing
> standing in our way is the inability of GHC's interpreter to run modules
> which use unboxed tuples. While there are a few modules within GHC which
> use unboxed tuples, none of them are particularly interesting for
> debugging purposes, so compiling them with -fobject-code should be fine.
> In principle this could be accomplished by,
>
> {-# OPTIONS_GHC -fobject-code #-}
>
> However, as explained in #10965, GHC sadly does not allow this. I spent
> a bit of time tonight trying to see if I could convince GHC to first
> manually build object code for the needed modules, and then load
> bytecode for the rest. Unfortunately recompilation checking fought me at
> every turn.
>
> The current state of my attempt can be found here [1]. It would be great
> if someone could pick it up. This will involve,
>
>  * Working out how to convince the GHC to use the object code for
>utils/Encoding.o instead of recompiling
>
>  * Identifying all of the modules which can't be byte-code compiled and
>add them to $obj_modules
>
>  * Chassing down whatever other issues that might pop up along the way
>
> I also wouldn't be surprised if you would need this GHC patch [2].
>

I would have thought that something like

:set -fobject-code
:load Main  -- or whatever
-- modify some source file
:set -fbyte-code
:load Main

should do the right thing, loading object code when it can, up to the first
module that has been modified more recently.  Of course you can't have any
object code modules that depend on byte-code modules, so if you modify
something too low down in the dependency graph then you'll have a lot of
interpreted modules, and you may end up trying to interpret something that
can't be interpreted because it has an unboxed tuple.  But for simple tests
it ought to work.  (I haven't tried this so I'm probably forgetting
something...)

Cheers
Simon



>
> Cheers,
>
> - Ben
>
>
> [1] https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e
> [2] http://git.haskell.org/ghc.git/commit/326931db9cdc26f2d47657c1f084b9
> 903fd46246
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Navigating GHC proposals

[Simon Peyton Jones via ghc-devs]

I don't think there is a way to go from the rendered proposal to the pull 
request, other than the "back" button in your browser.

Seriously?  But the rendered proposal is the useful link to send to people.  
There _must_ be a way, even if its indirect.

Simon

From: Simon Marlow [mailto:marlo...@gmail.com]
Sent: 09 January 2017 16:03
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org; Richard Eisenberg 
Subject: Re: Navigating GHC proposals

I don't think there is a way to go from the rendered proposal to the pull 
request, other than the "back" button in your browser.

The constraint-vs-type proposal seems a little bit weird in that it actually 
has a branch in the ghc-proposals repository itself, rather than being a pull 
request from a fork in @goldfire's account.  Richard, was that intentional?

On 9 January 2017 at 13:55, Simon Peyton Jones via ghc-devs 
> wrote:
Once I am looking the rendered form of a GHC proposal, eg
https://github.com/ghc-proposals/ghc-proposals/blob/rae/constraint-vs-type/proposals/-constraint-vs-type.rst
how can I find my way to the “conversation” for that proposal, so I can comment 
on it?
https://github.com/ghc-proposals/ghc-proposals/pull/32

Once more, I am lost in a maze of twisty little Githup passages.  I clearly 
have not yet internalised an accurate model of what Github is thinking
Thanks
Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Navigating GHC proposals

[Simon Marlow]

I don't think there is a way to go from the rendered proposal to the pull
request, other than the "back" button in your browser.

The constraint-vs-type proposal seems a little bit weird in that it
actually has a branch in the ghc-proposals repository itself, rather than
being a pull request from a fork in @goldfire's account.  Richard, was that
intentional?

On 9 January 2017 at 13:55, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Once I am looking the rendered form of a GHC proposal, eg
>
> https://github.com/ghc-proposals/ghc-proposals/blob/
> rae/constraint-vs-type/proposals/-constraint-vs-type.rst
>
> how can I find my way to the “conversation” for that proposal, so I can
> comment on it?
>
> https://github.com/ghc-proposals/ghc-proposals/pull/32
>
>
>
> Once more, I am lost in a maze of twisty little Githup passages.  I
> clearly have not yet internalised an accurate model of what Github is
> thinking
>
> Thanks
>
> Simon
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phabricator upgrade underway

[Ben Gamari]

Ben Gamari  writes:

> Hello everyone,
>
> I'll be bringing down Phabricator for an upgrade in a few minutes. I'll
> let you know when things are back up.
>
Hello everyone,

The upgrade should now be complete. Feel free to resume your typical
Phabrication. I've done some testing but let me know if you encounter
any trouble.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Navigating GHC proposals

[Simon Peyton Jones via ghc-devs]

Once I am looking the rendered form of a GHC proposal, eg
https://github.com/ghc-proposals/ghc-proposals/blob/rae/constraint-vs-type/proposals/-constraint-vs-type.rst
how can I find my way to the “conversation” for that proposal, so I can comment 
on it?
https://github.com/ghc-proposals/ghc-proposals/pull/32

Once more, I am lost in a maze of twisty little Githup passages.  I clearly 
have not yet internalised an accurate model of what Github is thinking
Thanks
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

With regards to the other two points that Ben made.

I solicited the opinion of a few people when I first made the
prototype and the reaction was that it didn't matter to them. We
should really make this decision based on the opinions of people who
are high utilisers of the tracker. The experience should be better for
occasional contributors as there are many more options for
authentication and clearer control over notifications.

The interaction with the stable branch was something I had not
considered yet so thank you for bringing this up. I spent yesterday
looking at the situation and it doesn't look like there is anything
immediate which could help with release management. People in
#phabricator told me that we shouldn't use Releeph as there were plans
to change it significantly and it wasn't a finished product. They
pointed me to https://secure.phabricator.com/T9530 and
https://secure.phabricator.com/D16981 which describe the future of the
feature. In particular, the "Facebook-Style Cherry-Picks /
Phabricator-Style Stable / Backporting" work flow looks close to
current practices. This being said, it isn't clear at all when they
plan to introduce these features.

Custom forms are also a good idea. We could even modify the URLs
sometimes produced by the compiler for panics to prefill certain
fields of the form.
(For example.. 
http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/maniphest/task/edit/?projects=Inlining=Simplified%20Ticks%20Exhausted)

Matt

On Sun, Jan 8, 2017 at 5:40 AM, Ben Gamari  wrote:
> Matthew Pickering  writes:
>
>> Dear devs,
>>
> Hi Matthew and Dan,
>
> First, thanks for your work on this; it is an impressive effort.
> Reconstructing a decade of tickets with broken markup, tricky syntax,
> and a strange data model is no easy task. Good work so far!
>
> On the whole I am pleasantly surprised by how nicely Maniphest seems to
> hang together. I have pasted my notes from my own reflection on the pros
> and cons of both systems below. On re-reading them, it seems clear that
> Trac does leave us with a number of issues which Phabricator may
> resolve.
>
> As I've expressed in the past, I think we should consider preservation
> of ticket numbers to be an absolute requirement of any migration. To do
> otherwise imposes a small cost on a large number of people for a
> very long time with little benefit. GHC infrastructure exists to
> support GHC, not the other way around.
>
> However, ticket numbers notwithstanding I think I would be fine moving
> in this direction if the community agrees that this is the direction we
> want to go in.
>
> There are a few questions that remain outstanding, however:
>
>
> What do others think of this?
> =
>
> Does Phabricator address the concerns that others, including those
> outside of the usual GHC development community, have raised about our
> issue tracking in the past? It would be interesting to hear some outside
> voices.
>
>
> How do we handle the stable branch?
> ===
>
> One important role that the issue tracker plays is ensuring that
> patches are backported to the stable branch when appropriate. In Trac we
> handle this with a "merge" state (indicating that the ticket has been
> fixed in `master`, but the fix needs to be backported) and the milestone
> field (to indicate which release we want to backport to).
>
> A significant amount of GHC's maintenance load is spent backporting and
> updating tickets, so it's important that this process works smoothly and
> reliably. I think this is may be an area where Phabricator could
> improve the status quo since the workflow currently looks something like
> this,
>
>  1. Someone merges a patch to `master` fixing an issue; if the commit
> message mentions the ticket number then our infrastructure
> automatically leaves a comment referencing the commit on the ticket.
>
>  2. Someone (usually the committer) places the ticket in `merge` state
> and sets the milestone appropriately
>
>  3. I merge the patch to the stable branch
>
>  4. I close the ticket and manually leave a comment mentioning the SHA
> of the backported commit.
>
> In particular (4) is more work than it needs to be; ideally comment
> generation would be automated as it is for commits to `master` but
> Trac's comment-on-commit functionality is a bit limited, so this is
> currently not an option.
>
> I'm not sure what Phabricator's analogous workflow to the above might
> look like. It seems that Phabricator's Releeph module may be in part
> intended for this use-case, but it seems to have some unfortunate
> limitations (e.g. the inflexibility in branch naming) that make it hard
> to imagine it being usable in our case.
>
> Setting aside Releeph, perhaps the best solution would be to continue
> with our current workflow: we would retain the "status" state and
> milestone projects would take the place of the 

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

To first reply to the one specific reoccurring point about custom fields.

The problem with 'os' and 'architecture' is a philosophical one, in
what way are they any different to any other metadata for a ticket? I
am of the opinion that we should only include information when it is
relevant, a lot of the time these two fields are not.
Including the fields as a special case is in fact worse as users feel
obliged to complete them even when they are irrelevant. Users who are
interested in these platforms are interested in problems which are
specific.

These fields have been structured for over 10 years now, some options
have been barely used but still clutter all interfaces. Nearly 2000
tickets are tagged as relevant to `x86` which massively dwarfs the
other fields -- there is an assumption that unless otherwise stated
the problem is manifested on x86 as that is the default use case.
What's more, just by browsing tickets categorised with this meta data,
it is often evident from the title that the problem is on a
non-default operating system. The assumption in this case is some
debian derivation, users reporting issues on other operating systems
include the operating system prominently as they know it is not
standard. (For example -
https://ghc.haskell.org/trac/ghc/query?os=MacOS+X=priority)

Stats for architecture - https://phabricator.haskell.org/P133

Stats for operating system - https://phabricator.haskell.org/P134

I modified my local install of phab to add custom fields,

http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/M1/7/

The results were better than I remembered but I am unsatisfied that
they behave differently to projects and clutter up the description of
each ticket when they are "unset".


On the other hand, I think custom fields are suitable for things like
test case, wikipage etc. It is easy to add a field to carry over the
test case but I always found it a bit redundant as by looking at the
commit information you could work out which test is relevant to which
commit.

So to summarise I think..

Component -> Projects
OS -> (Sub)Projects
Arch -> (Sub)Projects
Keywords -> Projects
Version -> Remove (It is a proxy for date reported)
Milestone -> Project (Milestone)

Matt

On Sun, Jan 8, 2017 at 2:32 PM, Richard Eisenberg  wrote:
>
>> On Jan 8, 2017, at 12:40 AM, Ben Gamari  wrote:
>>
>> * Metadata: Custom fields are supported.
>
> In agreement with your comments above, I'm glad to see this. Trac's metadata 
> currently is suboptimal, but I don't think this means we should throw out the 
> ability to have structured metadata in its entirety.
>
>>
>> * Flexible user interface: Custom fields can be hidden from the new
>>   ticket form to prevent user confusion.
>
> Yay.
>
>>
>> * Familiarity: Many users may feel more at home in Phabricator's interface;
>>   reMarkup's similarity to Markdown also helps.
>
> Nitpick: Do we have any control over this? (I doubt it.) I find switching 
> between GitHub Markdown, RST, and reMarkup to be a low-grade but constant 
> annoyance.
>>
>> * Legibility:
>
> I seem to recall that Phab originally used gray-on-white in Diffs, but we 
> were able to fix with some CSS. (Or did it require upstream intervention?) 
> Perhaps we can do something similar here. I find the modern trend to use 
> lower-contrast interfaces utterly maddening.
>
>>
>> What does Trac do well?
>> ---
>>
>> * Convenient cross-referencing: while the syntax is a bit odd, once you
>>   acclimate it is quite liberating to be able to precisely
>>   cross-reference tickets, wiki documents, and comments without copying
>>   links around.
>
> Yesyesyes.
>
>>
>> * Automation of ticket lifecycle: Trac tickets progress through their
>>   lifecycle (e.g. from "new" to "patch" to "merge" to "closed"
>>   statuses) through predefined actions. This means that moving a ticket
>>   through its lifecycle typically only requires one click and the right
>>   thing happens with no additional effort. I think this is a great model,
>>   although in practice it's not clear how much we benefit from it
>>   compared to a typical Maniphest workflow.
>
> I'm less convinced about this benefit of Trac. For instance, if I close a 
> ticket in error, I lose ownership. Then I have to reopen but cannot set an 
> owner at the same time. Maybe it's just a configuration issue, but I imagine 
> we have experienced devs doing ticket-state management and don't need strict 
> controls here.
>>
>>
>> What does Trac do poorly?
>> -
>>
>> * Active development: Trac is largely a stagnant project.
>
> I was unaware of this. This is a significant downside in my opinion.
>
>> * Safety: I have personally lost probably a half-dozen hours of my life
>>   to Trac eating comments.
>
> That's odd. I have not had this experience.
>
>>
>> * Relations between tickets: Trac has essentially no first-class notion
>>   of ticket relatedness. Even duplicate tickets