GHC on Windows (extended/broad discussion)

Sun Nov 2 21:59:26 UTC 2014

Hi Austin,

thanks for the explanation. All of this makes sense. I was just thinking
that maybe it would make sense to have a couple more reviewers with a
mandate to deal with cleanups quickly before you get to the juicier
reviews, the ones that actually need attention / routing to interested
parties. On the other hand, going through the queue once a day is pretty
good, and if you think you can manage that, sounds great! (I am not just
speaking for myself, but for the project and for other potential
contributors - fast turnaround time is always motivating.)

On Thu, Oct 30, 2014 at 9:38 PM, Austin Seipp <austin at well-typed.com> wrote:

> Hey Gintautas,
>
> Yes, I apologize about that (and I missed this request in my quick
> read over this email yesterday). To be clear, I apologize if my
> review/merge latencies are too long. :) What normally happens it that
> I review and merge patches in bulk, about once or twice a week. I'll
> review about, say, a dozen patches one day, and wait a few days for
> more to come in, then sweep up everything in that time at once.
>
> So there are two things: a review latency, *and* a merge latency.
>
> However, two things are also clear:
>
>  1) This is annoying for people who submit 'rapid improvements', e.g.
> in the process of working on GHC, you may fix 4 or 5 things, and then
> not having those in the mainline is a bit of a drain!
>  2) Phabricator building patches actually means the merge latency can
> be *shorter*, because in the past, we'd always have to double check if
> a patch worked in the first place (so it took *even longer* before!)
>
> Another thing is that I'm the primary person who lands things off
> Phabricator, although occasionally other people do too. This is
> somewhat suboptimal in some cases, since really, providing something
> has the OK (from me or someone else), anyone should be able to merge
> it. So I think this can be improved too.
>
> Finally, it's also worth mentioning that Phabricator reviews are
> special (and unlike GitHub) in that people who are *not* reviewers *do
> not* see the patch by default! That means if I am the *only* person on
> the review, it is pretty high guarantee that the review will only be
> done by me, and it will only be merged by me, unless I poke someone
> else. Others can see your review using a slightly different search
> criterion, however, but that's not the default.
>
> Note this is not a mistake - it is intentional in the design. Why?
> Because realistically, I'd say for about 85% of the patches that come
> in, they are irrelevant to 90% of all GHC developers, and
> historically, 90% of developers will never bother committing it
> either. It is often pointless to spam them with emails, and enlarging
> their review queue beyond what's necessary makes things even *worse*
> for them, since they can't tell what may really deserve their
> attention. I do want more people reviewing code actively - but to do
> that, there must be a tradeoff - we should try and keep contributor
> burden low. Most developers are just our friends after all, including
> you - not paid GHC hackers! I don't want to overburden you; we need
> you!
>
> I am one of the exceptions to this: I realistically care and want to
> see about 95% of all patches that go into the tree, at least to keep
> up to date with what's happening, and also to ensure things get proper
> oversight - by, say, adding someone else to a review who I want to
> look at it. This is why I'm the common denominator, and a reviewer of
> almost every patch (and I think I'm fairly keen on who might care
> about what).
>
> However it's clear that if this is slowing you down we should try to
> fix it - we want you to help after all! We already have nearly 40
> people with commit rights to GHC, and you've clearly dedicated
> yourself to helping. That's fantastic. Perhaps it's time for you to
> enter the fray as well so I can get out of your way. :) But I do still
> want you to submit code reviews, as everyone else does - it really
> does help everyone, and increases a sense of shared ownership, IMO.
>
> In light of this though, I do think I need to ramp up my merge
> frequency. So how does a plan of just trying to merge all outstanding
> patches every day sound? This is normally very trivial amounts of time
> these days, considering Phabricator tends to catch the most obvious
> failures.
>
> BTW: I merged your pull request on the Win32 repository, so we can
> update MinGW - I didn't realize that it was open at all, and in fact I
> completely forgot I had permissions to merge things on that
> repository! Most of the external library management is normally dealt
> with by Herbert or individual maintainers.
>
> On Wed, Oct 29, 2014 at 6:36 AM, Gintautas Miliauskas
> <gintautas at miliauskas.lt> wrote:
> > By the way, regarding that repository, could someone merge my pull
> request?
> >
> > In general, it's a bit frustrating how a lot of the patches in the
> > Phabricator queue seem to take a while to get noticed. Don't take it
> > personally, I'm just sharing my impressions, but I do feel it's taking
> away
> > some momentum - not good for me & other contributors, and not good for
> the
> > project. I know reviewers are understaffed, maybe consider spreading
> commit
> > rights a bit more widely until the situation improves?
> >
> > On Wed, Oct 29, 2014 at 11:04 AM, Herbert Valerio Riedel
> > <hvriedel at gmail.com> wrote:
> >>
> >> On 2014-10-29 at 10:59:18 +0100, Phyx wrote:
> >>
> >> [...]
> >>
> >> >> The Win32 package for example, is dreadfully lacking in
> >> >> maintainership. While we merge patches, it would be great to see a
> >> >> Windows developer spearhead and clean it up
> >> >
> >> > A while back I was looking at adding some functionality to this
> >> > package, but could never figure out which one was actually being
> >> > used. I think there are multiple repositories out there.
> >>
> >> I'm not sure which multiple repositories you have seen, but
> >>
> >>   http://hackage.haskell.org/package/Win32
> >>
> >> points quite clearly to
> >>
> >>   https://github.com/haskell/win32
> >>
> >> and that's the official upstream repository GHC tracks (via a locally
> >> mirrored repo at git.haskell.org)
> >>
> >> Cheers,
> >>   hvr
> >
> >
> >
> >
> > --
> > Gintautas Miliauskas
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>

-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/aecf0773/attachment-0001.html>