Re: How, precisely, can we improve?

[Herbert Valerio Riedel]

On 2016-09-28 at 03:51:22 +0200, Richard Eisenberg wrote:

[...]

> Despite agreeing that wikis are sometimes wonky, I thought of a solid
> reason against moving: we lose the Trac integration. A Trac wiki page
> can easily link to tickets and individual comments, and can use
> dynamic features such as lists of active tickets. These are useful and
> well-used features. I don't know what's best here, but thinking about
> the real loss associated with moving away from these features gives me
> pause.

I'd like to emphasize this point; Trac's main strength, design
philosophy, and selling point is its tight integration between SCM, Wiki
and Issue tracking and resulting synergies (same markup features,
extensions, syntax usable seamless), whereas the issue tracking part is
its strongest feature.

If you rip away its Wiki (and replace it by something
decoupled/non-integrated as e.g. GitHub's Git-backed Wiki[1]), you
weaken it to the point where it becomes quite harder to argue to keep
Trac at all. It's already sub-optimal we spread discussions/information
across Trac and Phabricator (you often have to read both, the Diff
discussions and the associated Trac ticket discussion to get the full
picture); I doubt a 3rd more or less isolated tool which weakens
cohesion would improve things.


 [1]: Personally, I consider GitHub's Wiki quite weak and inconvenient
  to use.  It's stylesheet is not as optimised as Trac's and
  structuring the content is also significantly worse than with
  Trac. And finally GH-flavoured Markdown is very limiting compared
  to Trac's rich extensible wiki syntax; Github's Wiki doesn't even
  recognize #123 or Git-shas like 993d20a2e9b8fb29a (and then
  provide mouse-over hoover texts with a title of the respective
  referenced commit or ticket); you have to paste full urls and
  manually include a title.

  So IMO Github's wiki is not suitable for GHC's use at all.

  A highly customized/forked Gitit instance, however, may be a more
  reasonable alternative, but then the question is who is gonna
  customize, implement and maintain it. Or we can drop the idea of a
  wiki altogether, and go for statically generated docs. Then we
  could just keep the wiki-content as restructedText (which btw is
  more expressive and extensible than .md) and have sphinx generated
  output. But then that's a totally different medium compared to a
  Wiki...

  However, I'm still missing a compelling reason in this discussion
  to justify the cost of changing the status-quo.

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

Re: How, precisely, can we improve?

[Alan & Kim Zimmerman]

For me the biggest problem is that each of the three Wiki's has a different
markup syntax.

So the mental motivation to do anything is tempered by having to look up
everything to make sure you are using the right markup for *this* Wiki.

Reducing it to one, wherever it is, would help a lot.

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

Re: How, precisely, can we improve?

[Moritz Angermann]

Friends,

after the recent discussion here and on #ghc, I’ve taken
the liberty to extract a small part of this into a
proposal[1].  In essence this does not cover *all* of the
wiki, but the commentary and documentation part, after
Herbert mentioned that would be something he could see
happening.

So let’s see if we can make this happen!

Cheers,
 Moritz

--
[1]: https://github.com/ghc-proposals/ghc-proposals/pull/10
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

On Wednesday, September 28, 2016, Eric Seidel  wrote:

> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
> > Moritz Angermann > writes:
> >
> > > All that arc essentially does is, compute the diff from an offset
> > > (e.g. master) to the current HEAD and upload that to a new or existing
> > > (--update) differential. It also adds some meta information about the
> > > range, such that arc patch supposedly knows into which commit to apply
> > > the patch to.
> > >
> > Sure, but this leads to generally unreviewable patches IMHO. In order to
> > stay sane I generally split up my work into a set of standalone patches
> > with git rebase and then create a Diff of each of these commits.
> > Phabricator supports this by having a notion of dependencies between
> > Diffs, but arcanist has no sensible scheme for taking a branch and
> > conveniently producing a series of Diffs.
>
> I completely understand how this would be frustrating for core
> contributors (more specifically for people submitting large patches),
> but for new or casual contributors it's actually quite freeing. I don't
> have to worry about how messy my local history gets, because arc will
> throw it all away regardless! It absolves me of an extra responsibility,
> and lowers the barrier to contributing.


I dislike this workflow because I am already used to doing a lot of git
rebasing / amending / auto squashing.  So using arc means taking away my
ability to write multi commit stories of how the change was crafted. For
large changes there are often multiple logical inter related steps.
Squashing them into one big commit makes it much harder to review.  I can
easily do that myself by marking everything as squash in a rebase. It feels
like arcanist is just taking away power, not giving it (note i have not
used it much - voice of a newbie here)

I am beginning to change my feelings on this, away from thinking of GitHub
as an auxilliary source of didferentials.  Instead perhaps GitHub's new
review system may be the way forward for GHC. It allows you to easily use
git in the way it's meant to be used.

-Michael


>
> It would be nice to support both workflows though :)
> ___
> 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: How, precisely, can we improve?

[Takenobu Tani]

Hi Carter,

Thank you very much :)

We love haskell,
Takenobu


2016-09-28 22:29 GMT+09:00 Carter Schonwald :

> I like your perspective on this
>
>
> On Wednesday, September 28, 2016, Takenobu Tani 
> wrote:
>
>> Apologies if I’m missing context.
>>
>>
>>
>> Potential contributors need information from wiki.
>>
>> I feel current wiki’s problems are following:
>>
>>
>>
>>   (a) reachability
>>
>> "Where is the page I need?"
>>
>>
>>
>>   (b) outdated pages
>>
>> "Is this page up-to-date?"
>>
>>
>>
>>   (c) update method
>>
>> "How Can I update the page?"
>>
>>
>>
>>
>>
>> About (a):
>>
>>
>>
>> It's difficult to find pages they need. Maybe reasons are following:
>>
>>   * We have multiple wiki sites.
>>
>>   * Desired contents structure is different for each member.
>>
>>
>>
>> So single wiki site is not enough from latter.
>>
>>
>>
>> Therefore, what about "a search system for multiple wiki sites"?
>>
>>
>>
>>
>>
>> About (b):
>>
>>
>>
>> Haskell's evolution is fast.
>>
>> New contributor encounters sometimes outdated pages.
>>
>> But they don't still know how to correct them.
>>
>>
>>
>> Therefore, what about putting "outdated mark" to the page by them?
>>
>>
>>
>> They can easily contribute.
>>
>> And if possible, they send update request with any way.
>>
>> We’ll preferentially update many requested pages.
>>
>>
>>
>>
>>
>> About (c):
>>
>>
>>
>> We have multiple wiki sites. Someone is unfamiliar about them.
>>
>> Github is one of the solutions for new contents.
>>
>> But I don't have idea about this for current contents.
>>
>>
>>
>> Regards,
>>
>> Takenobu
>>
>>
>>
>> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg :
>>
>>> I'm quite leery of using a new site (readthedocs.org), as it creates
>>> yet another platform for contributors to understand. Reducing the number of
>>> platforms has been a fairly clearly-stated goal of these recent
>>> conversations, as I've read it.
>>>
>>> Despite agreeing that wikis are sometimes wonky, I thought of a solid
>>> reason against moving: we lose the Trac integration. A Trac wiki page can
>>> easily link to tickets and individual comments, and can use dynamic
>>> features such as lists of active tickets. These are useful and well-used
>>> features. I don't know what's best here, but thinking about the real loss
>>> associated with moving away from these features gives me pause.
>>>
>>> Richard
>>>
>>> > On Sep 27, 2016, at 5:58 PM, Michael Sloan  wrote:
>>> >
>>> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel  wrote:
>>> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote:
>>> >>> Yes, I agree with Michael’s observations in the blog post. However,
>>> one
>>> >>> thing that’s easier about a wiki is that the editing process is much
>>> more
>>> >>> lightweight than making a PR.
>>> >>>
>>> >>> But GitHub has a wonderful feature (that I have rarely used) that
>>> >>> mitigates this problem. Viewing a file in GitHub offers a little
>>> pencil
>>> >>> icon in the top-right. It allows you to make arbitrary changes in the
>>> >>> file and then automates the construction of a PR. The owner of the
>>> file
>>> >>> can then accept the PR very, very easily. If the editor has commit
>>> >>> rights, you can make your edits into a commit right away. No need to
>>> >>> fork, pull and push.
>>> >>
>>> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely
>>> >> rendered and inter-linked pages *and* have the option for web-based or
>>> >> git-based editing. Though, based on my limited experience with GitHub
>>> >> wikis, I wonder if they would scale to the size of GHC's wiki..
>>> >
>>> > I agree, I don't think GitHub wikis are sufficient for GHC.  We've
>>> > tried using GitHub wikis, and found that they were clunkier than just
>>> > having wiki / docs in your repo.  GHC would probably want to have a
>>> > separate docs repo, as otherwise the commit history will get filled
>>> > with commits related to proposals, etc.
>>> >
>>> > It may be worth considering a similar approach with the GHC
>>> > documentation.  We've had great success in stack with using
>>> > https://readthedocs.org/ .  The way this works is that you have a
>>> > branch that readthedocs points at ("stable"), which provides the
>>> > current version to display.  I realize that ghc would want to have
>>> > multiple versions of the docs up, but I'm sure that's feasible.
>>> >
>>> > Github itself has pretty nice markdown rendering, and the ability to
>>> > edit directly.  Note that there is no GitHub lock-in here - it is just
>>> > a collection of markdown files, organized however you like them.
>>> >
>>> > The risk with such a migration is that the old wiki(s?) don't get
>>> > fully migrated and shut down.  If that happens, then information will
>>> > be even more spread out and hard to find.  Perhaps we can use pandoc
>>> > to automatically migrate much of the wiki content to markdown?  It
>>> > probably will not be a lossfree conversion.
>>> >
>>> >> There's also a tool called gi

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Christopher Allen]

>Instead perhaps GitHub's new review system may be the way forward for GHC. It 
>allows you to easily use git in the way it's meant to be used.

Many problems are caused by letting your inner tinkerer/genius tailor
dictate how things should be dealt with. Better to cut the gordian
knot. I think Michael's right.

On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan  wrote:
>
>
> On Wednesday, September 28, 2016, Eric Seidel  wrote:
>>
>> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
>> > Moritz Angermann  writes:
>> >
>> > > All that arc essentially does is, compute the diff from an offset
>> > > (e.g. master) to the current HEAD and upload that to a new or existing
>> > > (--update) differential. It also adds some meta information about the
>> > > range, such that arc patch supposedly knows into which commit to apply
>> > > the patch to.
>> > >
>> > Sure, but this leads to generally unreviewable patches IMHO. In order to
>> > stay sane I generally split up my work into a set of standalone patches
>> > with git rebase and then create a Diff of each of these commits.
>> > Phabricator supports this by having a notion of dependencies between
>> > Diffs, but arcanist has no sensible scheme for taking a branch and
>> > conveniently producing a series of Diffs.
>>
>> I completely understand how this would be frustrating for core
>> contributors (more specifically for people submitting large patches),
>> but for new or casual contributors it's actually quite freeing. I don't
>> have to worry about how messy my local history gets, because arc will
>> throw it all away regardless! It absolves me of an extra responsibility,
>> and lowers the barrier to contributing.
>
>
> I dislike this workflow because I am already used to doing a lot of git
> rebasing / amending / auto squashing.  So using arc means taking away my
> ability to write multi commit stories of how the change was crafted. For
> large changes there are often multiple logical inter related steps.
> Squashing them into one big commit makes it much harder to review.  I can
> easily do that myself by marking everything as squash in a rebase. It feels
> like arcanist is just taking away power, not giving it (note i have not used
> it much - voice of a newbie here)
>
> I am beginning to change my feelings on this, away from thinking of GitHub
> as an auxilliary source of didferentials.  Instead perhaps GitHub's new
> review system may be the way forward for GHC. It allows you to easily use
> git in the way it's meant to be used.
>
> -Michael
>
>>
>>
>> It would be nice to support both workflows though :)
>> ___
>> 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
>



-- 
Chris Allen
Currently working on http://haskellbook.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC 8.0.2 status

[Ben Gamari]

Hello everyone,

The week before ICFP I was able to get the ghc-8.0 branch ready for an
8.0.2 release, which I intended to cut this week. In the intervening
time an additional rather serious issue was reported affected Mac OS X
Sierra (#12479). Since this issue affects the usability of GHC on the
new OS X release, we'll be deferring the 8.0.2 release until it has been
resolved.

While there appears to be an actionable path forward on this ticket, we
will need someone with an affected machine and an understanding of GHC's
use of dynamic linking to step up to implement. Otherwise it looks like
the release will be delayed at least until October 9, when darchon has
time to have a look.

Sorry to be the bearer of bad news!

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: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Richard Eisenberg]

I have tried to gather the ideas from this thread into a formal proposal: 
https://github.com/ghc-proposals/ghc-proposals/pull/11

Please feel free to make suggestions to improve this, especially if I've 
captured anyone's contributions incorrectly.

-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
Asst. Prof. of Computer Science
Bryn Mawr College
Bryn Mawr, PA, USA
cs.brynmawr.edu/~rae

> On Sep 29, 2016, at 10:20 AM, Christopher Allen  wrote:
> 
>> Instead perhaps GitHub's new review system may be the way forward for GHC. 
>> It allows you to easily use git in the way it's meant to be used.
> 
> Many problems are caused by letting your inner tinkerer/genius tailor
> dictate how things should be dealt with. Better to cut the gordian
> knot. I think Michael's right.
> 
> On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan  wrote:
>> 
>> 
>> On Wednesday, September 28, 2016, Eric Seidel  wrote:
>>> 
>>> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
 Moritz Angermann  writes:
 
> All that arc essentially does is, compute the diff from an offset
> (e.g. master) to the current HEAD and upload that to a new or existing
> (--update) differential. It also adds some meta information about the
> range, such that arc patch supposedly knows into which commit to apply
> the patch to.
> 
 Sure, but this leads to generally unreviewable patches IMHO. In order to
 stay sane I generally split up my work into a set of standalone patches
 with git rebase and then create a Diff of each of these commits.
 Phabricator supports this by having a notion of dependencies between
 Diffs, but arcanist has no sensible scheme for taking a branch and
 conveniently producing a series of Diffs.
>>> 
>>> I completely understand how this would be frustrating for core
>>> contributors (more specifically for people submitting large patches),
>>> but for new or casual contributors it's actually quite freeing. I don't
>>> have to worry about how messy my local history gets, because arc will
>>> throw it all away regardless! It absolves me of an extra responsibility,
>>> and lowers the barrier to contributing.
>> 
>> 
>> I dislike this workflow because I am already used to doing a lot of git
>> rebasing / amending / auto squashing.  So using arc means taking away my
>> ability to write multi commit stories of how the change was crafted. For
>> large changes there are often multiple logical inter related steps.
>> Squashing them into one big commit makes it much harder to review.  I can
>> easily do that myself by marking everything as squash in a rebase. It feels
>> like arcanist is just taking away power, not giving it (note i have not used
>> it much - voice of a newbie here)
>> 
>> I am beginning to change my feelings on this, away from thinking of GitHub
>> as an auxilliary source of didferentials.  Instead perhaps GitHub's new
>> review system may be the way forward for GHC. It allows you to easily use
>> git in the way it's meant to be used.
>> 
>> -Michael
>> 
>>> 
>>> 
>>> It would be nice to support both workflows though :)
>>> ___
>>> 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
>> 
> 
> 
> 
> -- 
> Chris Allen
> Currently working on http://haskellbook.com
> ___
> 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: How, precisely, can we improve?

[Richard Eisenberg]

I've spent some time thinking about how and what to synthesize from this 
conversation. Moritz has captured much of these ideas in the proposal he 
submitted. Thanks.

But that proposal tackles only one part of the problem: what to do in the 
future. It does not address the insufficiencies of the wiki as it now stands, 
and these drawbacks seem to be the dangling fibers of this thread. Two specific 
complaints are that (1) search engines still find out-of-date documentation and 
(2) the wiki is not discoverable. I agree with both of these, but I can't think 
of any (easy) way to help either one.

For (1), the "obvious" solution is to pull old pages. However, old pages still 
serve as useful documentary evidence when we need to revisit a decision made in 
the past. I think simply deleting out-of-date pages may lose useful info. Could 
we remove the pages from the wiki but keep them somewhere else, beyond the 
all-seeing eye of Google? Perhaps -- but where? I wouldn't want to keep it 
somewhere private, lest it be unavailable to the person that needs it. I think 
clearly labeling out-of-date info as such is the best compromise.

For (2), there is an index to the wiki: 
https://ghc.haskell.org/trac/ghc/wiki/TitleIndex   It's long and rambly, but 
may be of use. I agree that grepping would be nice. Does anyone know if there 
is a way to extract plaintext from a Trac wiki? I agree that making such a 
feature available would be helpful. In the future, though, even a git-backed 
collection will run into discoverability problems, unless someone continually 
keeps it organized. (It will be greppable, though.)

As to the point of shoring up existing infra vs. looking more broadly: I 
suppose I am interesting in shoring up the existing infra, but I'm considering 
"existing infra" to include all the platforms I'm aware of. This explicitly 
includes the idea of dropping, say, Trac entirely and moving exclusively to 
GitHub. I think that would be a terrible idea, but it's in scope in my 
thinking. What's *not* in scope (in my thinking) is the idea of creating new 
tools that do exactly what we want. We're all developers and can imagine 
wonderful things, but wonderful things do not come cheaply, and we are but poor.

So I'm at a loss of what to do about these remaining fibers. Concrete 
suggestions, anyone?

Richard

-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
Asst. Prof. of Computer Science
Bryn Mawr College
Bryn Mawr, PA, USA
cs.brynmawr.edu/~rae 
> On Sep 29, 2016, at 7:37 AM, Takenobu Tani  wrote:
> 
> Hi Carter,
> 
> Thank you very much :)
> 
> We love haskell,
> Takenobu
> 
> 
> 2016-09-28 22:29 GMT+09:00 Carter Schonwald  >:
> I like your perspective on this
> 
> 
> On Wednesday, September 28, 2016, Takenobu Tani  > wrote:
> Apologies if I’m missing context.
> 
>  
> Potential contributors need information from wiki.
> 
> I feel current wiki’s problems are following:
> 
>  
>   (a) reachability
> 
> "Where is the page I need?"
> 
>  
>   (b) outdated pages
> 
> "Is this page up-to-date?"
> 
>  
>   (c) update method
> 
> "How Can I update the page?"
> 
>  
>  
> About (a):
> 
>  
> It's difficult to find pages they need. Maybe reasons are following:
> 
>   * We have multiple wiki sites.
> 
>   * Desired contents structure is different for each member.
> 
>  
> So single wiki site is not enough from latter.
> 
>  
> Therefore, what about "a search system for multiple wiki sites"?
> 
>  
>  
> About (b):
> 
>  
> Haskell's evolution is fast.
> 
> New contributor encounters sometimes outdated pages.
> 
> But they don't still know how to correct them.
> 
>  
> Therefore, what about putting "outdated mark" to the page by them?
> 
>  
> They can easily contribute.
> 
> And if possible, they send update request with any way.
> 
> We’ll preferentially update many requested pages.
> 
>  
>  
> About (c):
> 
>  
> We have multiple wiki sites. Someone is unfamiliar about them.
> 
> Github is one of the solutions for new contents.
> 
> But I don't have idea about this for current contents.
> 
>  
> Regards,
> 
> Takenobu
> 
>  
> 
> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg >:
> I'm quite leery of using a new site (readthedocs.org 
> ), as it creates yet another platform for 
> contributors to understand. Reducing the number of platforms has been a 
> fairly clearly-stated goal of these recent conversations, as I've read it.
> 
> Despite agreeing that wikis are sometimes wonky, I thought of a solid reason 
> against moving: we lose the Trac integration. A Trac wiki page can easily 
> link to tickets and individual comments, and can use dynamic features such as 
> lists of active tickets. These are useful and well-used features. I don't 
> know what's best here, but thinking about the real loss associated with 
> moving away from these features gives me pause.
> 
> Richard
> 
> > On Sep 27, 2016

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Boespflug, Mathieu]

Hi Richard!

thanks for creating the pull request with a full proposal. You beat me to
it - tried writing up much the same before stopping for dinner, essentially
capturing just one of the points in Moritz's earlier (large) proposal.
Moritz, I would encourage you like Richard did earlier to split the
remaining points in your proposal into separate PR's too.

So Richard, I created a PR to your PR to add in a little bit more detail:
keeping the two mirrors in sync, role of the release manager to ensure that
adequate reviewers get identified so that patches don't go unnoticed by an
interested party who'd specifically want to review the patch on
Phabricator, etc.

https://github.com/goldfirere/ghc-proposals/pull/1

I also moved one of the two choices you mention to the "alternatives"
section of the document, thinking that's the pupose of the section.

On another note, I solicited an experience report from Gabriel Scherer
earlier this week. The Ocaml community likewise pondered using GitHub back
in 2014, and in fact lauched an experiment to that effect.  So I was
curious to hear how it went after 2 years of data.

You can see the announcement here:

http://thread.gmane.org/gmane.comp.lang.ocaml.platform/30

Gabriel tells me that the initial situation for Ocaml was different from
that of GHC: they had no formal code review tool in use, but would swap
around patches on the Mantis issue tracker. Be it as it may, it's
interesting to note just how much the number of contributions to Ocaml has
increased in recent years, after this experiment started:

https://github.com/ocaml/ocaml/graphs/contributors

This experiment is today considered a big success. A key ingredient I
gather is that Gabriel volunteered to triage the GitHub PR's and play the
go-between to make sure all Mantis users were aware of any proposed changes
relevant to them.

The key insight I would put forth here is that how-to-accept-patches and
where-to-review-them should be an agreement between the contributor and the
assigned reviewer(s), in particular for trivial changes. For any given
patch, provided the reviewer(s) is/are game, and provided all protential
reviewers are made aware of its existence, it shouldn't matter much whether
the patch came from Trac, Phabricator or GitHub.

PS: Gabriel was very kind to also point out that the LLVM community has
been big users of Phabricator and pondering introducing GitHub into the mix
too. The discussion there should be relevant to this thread:

http://lists.llvm.org/pipermail/llvm-dev/2016-May/100310.html

Best,

--
Mathieu Boespflug
Founder at http://tweag.io.

--
Mathieu Boespflug
Founder at http://tweag.io.

On 29 September 2016 at 20:55, Richard Eisenberg 
wrote:

> I have tried to gather the ideas from this thread into a formal proposal:
> https://github.com/ghc-proposals/ghc-proposals/pull/11
>
> Please feel free to make suggestions to improve this, especially if I've
> captured anyone's contributions incorrectly.
>
> -=-=-=-=-=-=-=-=-=-=-
> Richard A. Eisenberg
> Asst. Prof. of Computer Science
> Bryn Mawr College
> Bryn Mawr, PA, USA
> cs.brynmawr.edu/~rae
>
> > On Sep 29, 2016, at 10:20 AM, Christopher Allen 
> wrote:
> >
> >> Instead perhaps GitHub's new review system may be the way forward for
> GHC. It allows you to easily use git in the way it's meant to be used.
> >
> > Many problems are caused by letting your inner tinkerer/genius tailor
> > dictate how things should be dealt with. Better to cut the gordian
> > knot. I think Michael's right.
> >
> > On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan 
> wrote:
> >>
> >>
> >> On Wednesday, September 28, 2016, Eric Seidel  wrote:
> >>>
> >>> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
>  Moritz Angermann  writes:
> 
> > All that arc essentially does is, compute the diff from an offset
> > (e.g. master) to the current HEAD and upload that to a new or
> existing
> > (--update) differential. It also adds some meta information about the
> > range, such that arc patch supposedly knows into which commit to
> apply
> > the patch to.
> >
>  Sure, but this leads to generally unreviewable patches IMHO. In order
> to
>  stay sane I generally split up my work into a set of standalone
> patches
>  with git rebase and then create a Diff of each of these commits.
>  Phabricator supports this by having a notion of dependencies between
>  Diffs, but arcanist has no sensible scheme for taking a branch and
>  conveniently producing a series of Diffs.
> >>>
> >>> I completely understand how this would be frustrating for core
> >>> contributors (more specifically for people submitting large patches),
> >>> but for new or casual contributors it's actually quite freeing. I don't
> >>> have to worry about how messy my local history gets, because arc will
> >>> throw it all away regardless! It absolves me of an extra
> responsibility,
> >>> and lowers the barrier to contributing.
> >>
> >>
> >> I dislike this work

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

Thanks for the useful data point Mathieu. I think it should also be
noted that GHC contributions spiked after switching to phabricator so
it could just be the effect of moving to *some* code review tool.
Could you perhaps summarise the salient points in the LLVM thread? It
is very long with lots of discussion points.

FWIW, I think that we should accept pull requests but only if they are
mirrored and reviewed on phabricator.

This is important for three reasons:

1. Reviewers only need to look in one place and can clearly see when
they are expected to review. Herald rules will also not trigger if a
pull request is solely dealt with on github
which could mean the right eyes don't land on the ticket.
2. Pull requests (differentials) are able to be referred to by their
unique differential number rather than the pull request identifier
which clashes with trac ticket numbers.
3. Differentials integrate (and are able to be integrated) with the
existing infrastructure. I hope that in the future we improve this
integration by moving the issue tracker to maniphest.

Facebook have a bot which does the mirroring for some of their
repositories but it isn't open-sourced.

I believe we should be trying to consolidate rather than spread
everything even thinner.

Matt



On Thu, Sep 29, 2016 at 9:55 PM, Boespflug, Mathieu  wrote:
> Hi Richard!
>
> thanks for creating the pull request with a full proposal. You beat me to it
> - tried writing up much the same before stopping for dinner, essentially
> capturing just one of the points in Moritz's earlier (large) proposal.
> Moritz, I would encourage you like Richard did earlier to split the
> remaining points in your proposal into separate PR's too.
>
> So Richard, I created a PR to your PR to add in a little bit more detail:
> keeping the two mirrors in sync, role of the release manager to ensure that
> adequate reviewers get identified so that patches don't go unnoticed by an
> interested party who'd specifically want to review the patch on Phabricator,
> etc.
>
> https://github.com/goldfirere/ghc-proposals/pull/1
>
> I also moved one of the two choices you mention to the "alternatives"
> section of the document, thinking that's the pupose of the section.
>
> On another note, I solicited an experience report from Gabriel Scherer
> earlier this week. The Ocaml community likewise pondered using GitHub back
> in 2014, and in fact lauched an experiment to that effect.  So I was curious
> to hear how it went after 2 years of data.
>
> You can see the announcement here:
>
> http://thread.gmane.org/gmane.comp.lang.ocaml.platform/30
>
> Gabriel tells me that the initial situation for Ocaml was different from
> that of GHC: they had no formal code review tool in use, but would swap
> around patches on the Mantis issue tracker. Be it as it may, it's
> interesting to note just how much the number of contributions to Ocaml has
> increased in recent years, after this experiment started:
>
> https://github.com/ocaml/ocaml/graphs/contributors
>
> This experiment is today considered a big success. A key ingredient I gather
> is that Gabriel volunteered to triage the GitHub PR's and play the
> go-between to make sure all Mantis users were aware of any proposed changes
> relevant to them.
>
> The key insight I would put forth here is that how-to-accept-patches and
> where-to-review-them should be an agreement between the contributor and the
> assigned reviewer(s), in particular for trivial changes. For any given
> patch, provided the reviewer(s) is/are game, and provided all protential
> reviewers are made aware of its existence, it shouldn't matter much whether
> the patch came from Trac, Phabricator or GitHub.
>
> PS: Gabriel was very kind to also point out that the LLVM community has been
> big users of Phabricator and pondering introducing GitHub into the mix too.
> The discussion there should be relevant to this thread:
>
> http://lists.llvm.org/pipermail/llvm-dev/2016-May/100310.html
>
> Best,
>
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
> On 29 September 2016 at 20:55, Richard Eisenberg 
> wrote:
>>
>> I have tried to gather the ideas from this thread into a formal proposal:
>> https://github.com/ghc-proposals/ghc-proposals/pull/11
>>
>> Please feel free to make suggestions to improve this, especially if I've
>> captured anyone's contributions incorrectly.
>>
>> -=-=-=-=-=-=-=-=-=-=-
>> Richard A. Eisenberg
>> Asst. Prof. of Computer Science
>> Bryn Mawr College
>> Bryn Mawr, PA, USA
>> cs.brynmawr.edu/~rae
>>
>> > On Sep 29, 2016, at 10:20 AM, Christopher Allen 
>> > wrote:
>> >
>> >> Instead perhaps GitHub's new review system may be the way forward for
>> >> GHC. It allows you to easily use git in the way it's meant to be used.
>> >
>> > Many problems are caused by letting your inner tinkerer/genius tailor
>> > dictate how things should be dealt with. Better to cut the gordian
>> > knot. I think Michael's right.

Re: How, precisely, can we improve?

[Tom Murphy]

On Fri, Sep 30, 2016 at 4:14 AM, Richard Eisenberg 
wrote:

> I've spent some time thinking about how and what to synthesize from this
> conversation. Moritz has captured much of these ideas in the proposal he
> submitted. Thanks.
>
> But that proposal tackles only one part of the problem: what to do in the
> future. It does not address the insufficiencies of the wiki as it now
> stands, and these drawbacks seem to be the dangling fibers of this thread.
> Two specific complaints are that (1) search engines still find out-of-date
> documentation and (2) the wiki is not discoverable. I agree with both of
> these, but I can't think of any (easy) way to help either one.
>
> For (1), the "obvious" solution is to pull old pages. However, old pages
> still serve as useful documentary evidence when we need to revisit a
> decision made in the past. I think simply deleting out-of-date pages may
> lose useful info. Could we remove the pages from the wiki but keep them
> somewhere else, beyond the all-seeing eye of Google? Perhaps -- but where?
> I wouldn't want to keep it somewhere private, lest it be unavailable to the
> person that needs it. I think clearly labeling out-of-date info as such is
> the best compromise.
>
>
+1 to keeping (maybe with "this is old" labels): I would much rather have a
page with a series of pointers to how something was done a few years ago
than to have no information at all.

I'd also like to +1 the fact that having Trac's up-to-date ticket labels
(e.g. crossed-out links for completed tickets) is invaluable.

Tom



> For (2), there is an index to the wiki: https://ghc.haskell.org/
> trac/ghc/wiki/TitleIndex   It's long and rambly, but may be of use. I
> agree that grepping would be nice. Does anyone know if there is a way to
> extract plaintext from a Trac wiki? I agree that making such a feature
> available would be helpful. In the future, though, even a git-backed
> collection will run into discoverability problems, unless someone
> continually keeps it organized. (It will be greppable, though.)
>
> As to the point of shoring up existing infra vs. looking more broadly: I
> suppose I am interesting in shoring up the existing infra, but I'm
> considering "existing infra" to include all the platforms I'm aware of.
> This explicitly includes the idea of dropping, say, Trac entirely and
> moving exclusively to GitHub. I think that would be a terrible idea, but
> it's in scope in my thinking. What's *not* in scope (in my thinking) is the
> idea of creating new tools that do exactly what we want. We're all
> developers and can imagine wonderful things, but wonderful things do not
> come cheaply, and we are but poor.
>
> So I'm at a loss of what to do about these remaining fibers. Concrete
> suggestions, anyone?
>
> Richard
>
> -=-=-=-=-=-=-=-=-=-=-
> Richard A. Eisenberg
> Asst. Prof. of Computer Science
> Bryn Mawr College
> Bryn Mawr, PA, USA
> cs.brynmawr.edu/~rae
>
> On Sep 29, 2016, at 7:37 AM, Takenobu Tani  wrote:
>
> Hi Carter,
>
> Thank you very much :)
>
> We love haskell,
> Takenobu
>
>
> 2016-09-28 22:29 GMT+09:00 Carter Schonwald :
>
>> I like your perspective on this
>>
>>
>> On Wednesday, September 28, 2016, Takenobu Tani 
>> wrote:
>>
>>> Apologies if I’m missing context.
>>>
>>>
>>> Potential contributors need information from wiki.
>>>
>>> I feel current wiki’s problems are following:
>>>
>>>
>>>   (a) reachability
>>>
>>> "Where is the page I need?"
>>>
>>>
>>>   (b) outdated pages
>>>
>>> "Is this page up-to-date?"
>>>
>>>
>>>   (c) update method
>>>
>>> "How Can I update the page?"
>>>
>>>
>>>
>>> About (a):
>>>
>>>
>>> It's difficult to find pages they need. Maybe reasons are following:
>>>
>>>   * We have multiple wiki sites.
>>>
>>>   * Desired contents structure is different for each member.
>>>
>>>
>>> So single wiki site is not enough from latter.
>>>
>>>
>>> Therefore, what about "a search system for multiple wiki sites"?
>>>
>>>
>>>
>>> About (b):
>>>
>>>
>>> Haskell's evolution is fast.
>>>
>>> New contributor encounters sometimes outdated pages.
>>>
>>> But they don't still know how to correct them.
>>>
>>>
>>> Therefore, what about putting "outdated mark" to the page by them?
>>>
>>>
>>> They can easily contribute.
>>>
>>> And if possible, they send update request with any way.
>>>
>>> We’ll preferentially update many requested pages.
>>>
>>>
>>>
>>> About (c):
>>>
>>>
>>> We have multiple wiki sites. Someone is unfamiliar about them.
>>>
>>> Github is one of the solutions for new contents.
>>>
>>> But I don't have idea about this for current contents.
>>>
>>>
>>> Regards,
>>>
>>> Takenobu
>>>
>>>
>>> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg :
>>>
 I'm quite leery of using a new site (readthedocs.org), as it creates
 yet another platform for contributors to understand. Reducing the number of
 platforms has been a fairly clearly-stated goal of these recent
 conversations, as I've read it.

 Despite agreeing that wikis are 

Re: A few technical suggestions

[Richard Eisenberg]

In a sweep to make sure that the concerns raised here get heard, I see this 
great list of suggestions. I believe they have all been incorporated into  
https://github.com/ghc-proposals/ghc-proposals/pull/9, so please check there. 
Personally, I think these suggestions will get better discussion and be more 
actionable if broken up into smaller PRs that can easily be debated separately. 
However, I will leave it to others to make this decision and do the 
restructuring.

Thanks for these suggestions forward!
Richard

-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
Asst. Prof. of Computer Science
Bryn Mawr College
Bryn Mawr, PA, USA
cs.brynmawr.edu/~rae 
> On Sep 26, 2016, at 2:37 AM, loneti...@gmail.com wrote:
> 
> Hi All,
>  
> I wanted to give my own thoughts/suggestions for things we could do on the 
> short/medium term
> To make things a bit better. As a whole I may be one of the few who likes the 
> current setup so I 
> Propose enhancing the current toolset.
>  
> I find the mail patch to mailing list approach of GCC et al quite cumbersome 
> to be honest.
> And the discussion quickly becomes hard to follow as it branches  lot.
>  
> My proposals (sorry for the brevity, I can expand if needed):
>  
> * Link phab to github
> Phabricator seems to have build in OAuth support.
> As you'll likely need a github account anyway, why not
> also support github logins? This would reduce the barrier of
> needing multiple accounts that is often a complaint.
>  Would it be possible to maybe also extract the user's public
> key from github automatically? That would reduce one of the barriers as well.
> https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/
>  
> 
>  
> * Link Trac to github
> - used to login (OAuth support)
> - readonly issues (to begin with?).
>we already have a code mirror, why not mirror more content.
> - sync issues back between the two
> - gives us an ability to see which github users an issue affects
>since they can then reference it.
> - updates the users when an issue is fixed since it will be closed on GH.
> - Gives us an indication of the importance of the tickets
>  
> As a whole, I find Trac MUCH better for ticket triaging than Github or Phab,
> both of which seem to be quite bare and simple in what they provide. I am not
> in favor of ditching it. Also we have and continue to accept patches just 
> uploaded
> to Trac as a diff. We tend to ask people to upload it to phab for better 
> reviews
> and so it's attributed to them when we commit. Some don't (and we then do it 
> ourselves),
> most due. If they don't need another login then I suspect almost all would.
>  There's a (seemingly) actively maintained project that does all the above, 
> could we leverage it?
> https://github.com/trac-hacks/trac-github 
> 
> * There is a trac plugin to generate a new section on trac
>   /doc which allows you to render and edit documentations checked into repo.
>   Could this be used to allow easier editing of non generated documentation?
>   
>   It's currently based on SVN, but maybe a git one exists too?
>   https://github.com/trac-hacks/tracdocs 
> 
>  
> * Newcomers
> - Expose newcomers information more by creating a new landing page
> - Clean up build instructions. For windows, I have scripts to automate setup.
>Often heard complain is that it is hard, but never hear why it's hard.
>
>In any case, my setup script for a 100% unattended build env setup for 
> Windows
>are here: https://github.com/Mistuke/GhcDevelChoco/releases 
> 
>
>These are entirely self contained environments that can be removed by a 
> simple rm -rf /.
>You can have as many as you want on the same machine without them 
> interfering with eachother
>or with whatever else you might have done to your GHC already installed.
>
>It's not 100% production ready but it works and does so well.
>  
> * Updated Phab reviewers list to be more automated
> - Assign reviewers next to the static list (as is currently done)
>   to maybe also include significant contributors to that file?
>
>The reason for this is that currently it's always the same people 
> reviewing patches.
>Their time is spread thin. Particularly on less popular platforms it 
> basically comes
>down to 4 people.
> * Update trac linters and pre-commit linters to be the same.
> - particularly reject summaries that would be rejected on commit.
>Often when I try landing patches (especially from others) I have to
>edit the summary. Maybe arc should reject the diff if a push would fail?
>
>Also I want to say I love the summary document you have to fill in.
>It ensures useful information is there later when I

Re: A few technical suggestions

[Ben Gamari]

loneti...@gmail.com writes:

> Hi All,
>
Sorry Tamar, it seems I overlooked this.

> I wanted to give my own thoughts/suggestions for things we could do on the 
> short/medium term
> To make things a bit better. As a whole I may be one of the few who likes the 
> current setup so I 
> Propose enhancing the current toolset.
>
> I find the mail patch to mailing list approach of GCC et al quite cumbersome 
> to be honest.
> And the discussion quickly becomes hard to follow as it branches  lot.
>
> My proposals (sorry for the brevity, I can expand if needed):
>
> * Link phab to github
>Phabricator seems to have build in OAuth support.
>As you'll likely need a github account anyway, why not
>also support github logins? This would reduce the barrier of
>needing multiple accounts that is often a complaint.
>  
Our Phabricator instance already supports GitHub logins. This is indeed
my primary means of authentication.

>  Would it be possible to maybe also extract the user's public
>  key from github automatically? That would reduce one of the barriers as well.
>  
> https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/
>
Sadly it seems that Phacility may be reluctant to implement this [1].

> * Link Trac to github
>  - used to login (OAuth support)
>  - readonly issues (to begin with?).
>we already have a code mirror, why not mirror more content.

Unfortunately GitHub doesn't allow one to override the automatically
assigned ticket numbering, so we'd end up with two different sets of
ticket numbers. I think this would be worse than no mirror. This pretty
much sinks any possibility for using GitHub issues.

>  - sync issues back between the two
>  - gives us an ability to see which github users an issue affects
>since they can then reference it.
>  - updates the users when an issue is fixed since it will be closed on GH.
>  - Gives us an indication of the importance of the tickets
>
>  As a whole, I find Trac MUCH better for ticket triaging than Github or Phab,
>  both of which seem to be quite bare and simple in what they provide.

I agree that Trac's ticket system is great. It is without doubt much more 
capable
than GitHub, which would be quite painful given our ticket load. That
being said, I am beginning to waver its merits relative to Phabricator.
Matthew Pickering pointed out that Phabricator indeed supports custom
fields, which is what gives Trac much of its power (this and the ability
to define custom ticket workflows, which Phabricator does not support AFAIK).

>  I am not in favor of ditching it. Also we have and continue to accept
>  patches just uploaded to Trac as a diff. We tend to ask people to
>  upload it to phab for better reviews and so it's attributed to them
>  when we commit. Some don't (and we then do it ourselves), most due.
>  If they don't need another login then I suspect almost all would.
>  
I don't mind this. Trac tickets are relatively few and far between.

>  There's a (seemingly) actively maintained project that does all the above, 
> could we leverage it?
>  https://github.com/trac-hacks/trac-github
>  
Perhaps.

> * There is a trac plugin to generate a new section on trac
>   /doc which allows you to render and edit documentations checked into repo.
>   Could this be used to allow easier editing of non generated documentation?
>   
>   It's currently based on SVN, but maybe a git one exists too?
>   https://github.com/trac-hacks/tracdocs
>
> * Newcomers
>  - Expose newcomers information more by creating a new landing page
>  - Clean up build instructions. For windows, I have scripts to automate setup.
>Often heard complain is that it is hard, but never hear why it's hard.
>
>In any case, my setup script for a 100% unattended build env setup for 
> Windows
>are here: https://github.com/Mistuke/GhcDevelChoco/releases
>
>These are entirely self contained environments that can be removed by a 
> simple rm -rf /.
>You can have as many as you want on the same machine without them 
> interfering with eachother
>or with whatever else you might have done to your GHC already installed.
>
>It's not 100% production ready but it works and does so well.
>
> * Updated Phab reviewers list to be more automated
>  - Assign reviewers next to the static list (as is currently done)
>to maybe also include significant contributors to that file?
>
>The reason for this is that currently it's always the same people 
> reviewing patches.
>Their time is spread thin. Particularly on less popular platforms it 
> basically comes
>down to 4 people.
>  
Agreed. However, I suspect this would need to be a manual effort. There
is no easy way to achieve this with Herald as far as I know.

> * Update trac linters and pre-commit linters to be the same.
>  - particularly reject summaries that would be rejected on commit.
>Often when I try landing patches (especially from others) I have to
>   

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Matthew Pickering  writes:

> Thanks for the useful data point Mathieu. I think it should also be
> noted that GHC contributions spiked after switching to phabricator so
> it could just be the effect of moving to *some* code review tool.
> Could you perhaps summarise the salient points in the LLVM thread? It
> is very long with lots of discussion points.

As far as I know the LLVM folks were merely considering moving from SVN
to Git, using GitHub to host their reposistory. I don't believe that
moving to GitHub for issue tracking, code review, or any other
functionality was ever seriously on the table.

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