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

Mon Sep 26 06:49:31 UTC 2016

I dislike this approach, having to already deal with a project that does
patches via mailing lists it is very hard to follow conversations. As soon
as multiple people get involved things fall apart.

I have multiple mailing rules and other things just so I can keep track of
comments. And then volume makes patches disappear into a void.

We already have a lightweight process. Lots of people just attach the patch
to trac. And we still accept it.

Going to trac forces you to give me useful information about what you are
trying to fix. A mailing list doesn't force a submitter to give me basic
information about the patch. Such as which platform it effects.

Also you can use phabricator.haskell.org without arc. You can manually
upload a patch file to it.
Again,  phabricator's summerary file I find very useful. It may be annoying
for drive by commiters, but when I have to come back to this code a year or
so later, I need to know why it was added.

On Mon, Sep 26, 2016, 07:34 Michael Sloan <mgsloan at gmail.com> wrote:

> I like this solution a lot, Carter!
>
> Mailing patches directly to the ghc-devs list could be intimidating
> for newcomers.  Having a list specific to patch review could make the
> process less intimidating.  From a perspective of overall contribution
> intimidation, these 2 pages make it seem like a ton of extra work to
> contribute to GHC:
>
> 1) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs
> 2) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures
>
> Of course, I understand that these exist for a reason.  Contributing
> to GHC isn't easy, and it does need processes, and those processes
> should be followed!
>
> However, for documentation patches and minor fixes, these pages make
> it seem like you really have to put in quite a bit to get started, and
> that the process is bureaucratic.  Atop getting accounts setup and
> figuring out how to get ghc compiled, the amount of time investment to
> get in a simple patch already seems like it is on the order of hours,
> if not a full days worth of work.
>
> At the risk of accumulating spam, perhaps the list shouldn't even
> require membership?  Just have it filter based on containing an
> attachment (perhaps even require a "*.patch" attachment?)
>
> I also think that there should be an easy way to put a stop to
> iterating via email and sending .patch files, and escalate to a
> phabricator review.  Perhaps this could be scripted?  Is there any way
> for people to use phabricator without using archanist?  Not a
> criticism of the tech, but it is more to learn, and foreign to most.
>
>
> One thing I've learned from maintaining stack, is that it can be
> really helpful to accept patches that are imperfect.  Here's how this
> works:
>
> 1) Some user wants to fix something, and doesn't quite nail it.  Maybe
> makes some style mistakes, spelling errors in comments, or perhaps
> writes some part of the code in a less direct way than possible
>
> 2) If the overall change is an improvement and the fixes are easy, I
> go ahead and merge the imperfect patch, and then commit my own fixes
> to the issues I saw.  I then say something like "Thanks for the
> patch!!  I fixed a few things in e5cbda"
>
> I feel like this is a highly valuable approach.  The contributor
> appreciates being thanked, and also appreciates directly seeing the
> ways that their patch could have been better.
>
> This is antithetical to the "google style" of code review, where every
> single thing is nit-picked and the author must fix it.  I think that
> approach only works well when you already have an established
> membership to that culture of code review (particularly if you are
> getting paid for it).  With that approach, all of the bad behaviors
> get beaten out of contributors, and they eventually learn their
> lesson, and either leave or become good contributors.  I think this
> can scare some people off, that might otherwise become regular
> contributors.
>
>
> Who knows if this will work out, but I think it is really worth a
> shot!  Especially if the wiki is updated to indicate that there is now
> an "easy mode" for contributing to ghc.
>
> -Michael
>
> On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> > In writing the following huge wall of text, I had and idea that I think
> many
> > folks would find palatable:
> >
> > What if simple small patches (such as hypothetical drive by doc patches )
> > had a mailing list where folks could email the simple / small patches as
> > email attachments plus a body text that summarizes the patch, what it
> does,
> > and why it's simple!
> >
> > What's even nice about this is its future proof and even agnostic to how
> the
> > contributor made the change set locally! They could use mercurial or
> fossil
> > for all we care. Or github. Or whatever!
> >
> >
> >
> > My personal stance is that ghc already way easier to contribute to / get
> > involved with than it was 2-5 years ago.  This is even more impressive
> when
> > you consider the number of contributors (who aren't students) that focus
> on
> > ghc work full time has actually DECREASED over that period.
> >
> > Community engagement / management is a totally orthogonal skill from
> > contributing. Both take effort.  Guiding new contributors requires both.
> >
> > My personal stance is that ghc keeps on getting better and getting more
> > contributors.  And occasionally chatting about ways to make things better
> > that we have the bandwidth to do is something that should happen every
> year
> > or so. Like a health checkup.
> >
> > I suspect one funnel for improvement may be figuring out how to make it
> more
> > visible how many contributors / how actively deved various subsystems
> are.
> > I feel like many new folks veer towards subsystems that are already
> actively
> > worked on, which are often the ones that are both the most mature and
> thus
> > hardest to easily contribute to! Perhaps I should see if there's an easy
> way
> > to quantify that in a way that's easy to communicate to new contributors.
> > There's an interesting data presentation challenge in that!
> >
> > I've definitely found that for new potential contributors that orienting
> > them to focus on subsystem that's important but doesn't get much activity
> > leads to more successful first contributions. But that requires someone
> > actively helping orient folks, which I like to think I've helped out
> with at
> > points in recent years.  Making this something that's easy to point at /
> > discover along with "newcomer tickets" might help a lot
> >
> > Tweaking the way we do tickets or code review I think doesn't change the
> > important / fundamental challenges of doing a good patch for a project
> like
> > ghc or llvm.  (I think in some ways that llvm / gcc / clang are the right
> > size projects to compare ghc against )
> >
> >
> >
> > On Saturday, September 24, 2016, Brandon Allbery <allbery.b at gmail.com>
> > wrote:
> >>
> >>
> >> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty
> >> <chak at justtesting.org> wrote:
> >>>
> >>> Why are you so hostile to Chris? I don’t think that this is an
> >>> appropriate way to treat somebody who is making a suggestion in good
> faith.
> >>
> >>
> >> It may be in good faith. but it's not in good sense. There is a lot in
> the
> >> background that made Rust's setup possible, and he's not bringing that
> to
> >> the table, just assuming it'll somehow happen or that everyone else will
> >> drop everything for the next few months and make it happen. And I feel
> like
> >> he's being really pushy about committing already overworked people to
> this
> >> --- and insisting that anyone opposed must have a hidden agenda or
> otherwise
> >> cannot possibly have good reason to be opposed. It's not helpful at all;
> >> it's basically a good way to stall ghc for the next few months at least.
> >>
> >> --
> >> brandon s allbery kf8nh                               sine nomine
> >> associates
> >> allbery.b at gmail.com
> >> ballbery at sinenomine.net
> >> unix, openafs, kerberos, infrastructure, xmonad
> >> http://sinenomine.net
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160926/6a725c26/attachment.html>