Re: Trac to Phabricator (Maniphest) migration prototype

[Ben Gamari]

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 current "milestone"
field. If I'm not mistaken Phabricator can be configured to mention
commits on stable branches in the ticket history, so this should help
point (4).


Which fields should be preserved?
=

Our Trac instance associates a lot of structured metadata with each
ticket. I generally think that this is a good thing, especially compared
to the everything-is-a-tag model which I have found can quickly become
unmaintainable. Unfortunately, Trac makes our users pay for these fields
with a confusing ticket form.

It appears that Phabricator's Transactions [1] module may allow us to have
our cake and eat it too: we can define one form for users to create
tickets and another, more complete form for developer use. In light of
this I don't see why we would need to fall back to the
everything-is-a-tag. Matthew, what did you feel was
less-than-satisfactory about the proper-fields approach? I fear that
relevant metadata like GHC version, operating system and architecture
simply won't be provided unless the user is explicitly prompted; I
personally find the cue to be quite helpful. Presumably contributors can
set Herald rules for notification on these fields if they so desire.

In the particular case of the "Component" field, I personally try to
set this correctly when possible and have certainly found it useful as a
search criterion. However, I suspect it would be fine as a tag. I also
know that Simon PJ is quite fond of the test case field (although
few others as as diligent in keeping this one up to date).


How would we migrate and what will become of Trac?
==

The mechanics of migration will 

Lexical error in string continuation

[Harendra Kumar]

Hi devs,

I am making a change in runghc on the ghc master branch. When compiling the
following code (edited/new code in utils/runghc):

208 splitGhcNonGhcArgs :: [String] -> IO ([String], [String])
209 splitGhcNonGhcArgs args = do
210let (ghc, other) = break notAFlag args
211when (hasUnescapedGhcArgs ghc) $
212hPutStrLn stderr "yy\
213\ xx"

I get an error because of the string continuation at line 212. If I put the
backslashes on the same line I do not get any error. I have more string
continuations in the same file and they all work fine. This snippet works
fine with ghc-7.10.3/ghc-8.0.1 when compiled separately. Here is the error
message that I get:

utils/runghc/Main.hs:212:56: error:

lexical error in string/character literal at character 'x'

   |

212 | hPutStrLn stderr "yy\

   |^

utils/runghc/ghc.mk:30: recipe for target
'utils/runghc/dist-install/build/Main.dyn_o' failed

make[2]: *** [utils/runghc/dist-install/build/Main.dyn_o] Error 1

Makefile:122: recipe for target 'all_utils/runghc' failed

make[1]: *** [all_utils/runghc] Error 2

make[1]: Leaving directory '/vol/hosts/cueball/workspace/play/ghc'

../../mk/sub-makefile.mk:50: recipe for target 'all' failed

make: *** [all] Error 2


Any help will be appreciated. I can send the modified file if anyone wants
to reproduce/debug.

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

Phabricator upgrade tomorrow

[Ben Gamari]

Hello everyone!

Currently our Phabricator installation is quite old, based on a commit
from last July. Given that I have a bit of breathing room now between
8.0.2 and 8.2.1, I'd like to take this opportunity to do an upgrade
tomorrow if no one objects. Given that this is the first time I have
attempted an upgrade, I expect this may take a few hours in the middle
of the day EST. I would expect that the GHC Phabricator instance would
be down for much of this time.

Let me know if this will cause you undue burden.

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: GHC API 7.10 -> 8.0.1 (unusable due to missing or recursive dependencies)

[Edward Z. Yang]

Hi A.M.,

It's very possible that the list in DynFlags are accumulated in
reverse order to the flags that were provided.  The manual is
just talking about user provided flags.

You may also be interested in
https://downloads.haskell.org/~ghc/master/users-guide/extending_ghc.html#frontend-plugins

Edward

Excerpts from A.M.'s message of 2017-01-07 10:54:56 -0500:
> On 01/06/2017 10:37 PM, Edward Z. Yang wrote:
> > Hello A.M.,
> > 
> > In 8.0.1 package databases must be specified in the correct order,
> > whereas in 7.10 they could be done in any order. This problem
> > was fixed in 8.0.2, give it a try.
> 
> Thanks for the tip, Edward. That was it!
> 
> Following https://ghc.haskell.org/trac/ghc/ticket/12485 to
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html#package-databases,
> I read:
> 
> "By default, the stack contains just the global and the user’s package
> databases, in that order."
> 
> However, the order that works for me is:
> 
> extraPkgConfs = const (localPkgPaths ++ [GlobalPkgConf])
> 
> so is the description flipped or is the stack head at the end of the
> list? In any case, it's rather confusing, though I recognize that the
> above sentence is not referring to the GHC API in particular.
> 
> I now see that the wrong ordering caused me to be unable to load *any*
> packages from my sandbox.
> 
> Thanks for the fix!
> 
> Cheers,
> M
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC API 7.10 -> 8.0.1 (unusable due to missing or recursive dependencies)

[A.M.]

On 01/06/2017 10:37 PM, Edward Z. Yang wrote:
> Hello A.M.,
> 
> In 8.0.1 package databases must be specified in the correct order,
> whereas in 7.10 they could be done in any order. This problem
> was fixed in 8.0.2, give it a try.

Thanks for the tip, Edward. That was it!

Following https://ghc.haskell.org/trac/ghc/ticket/12485 to
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html#package-databases,
I read:

"By default, the stack contains just the global and the user’s package
databases, in that order."

However, the order that works for me is:

extraPkgConfs = const (localPkgPaths ++ [GlobalPkgConf])

so is the description flipped or is the stack head at the end of the
list? In any case, it's rather confusing, though I recognize that the
above sentence is not referring to the GHC API in particular.

I now see that the wrong ordering caused me to be unable to load *any*
packages from my sandbox.

Thanks for the fix!

Cheers,
M



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