Re: GHC release timing and future build infrastructure
Heya, I very much agree with the thoughts on the variability of the release cadence. The following is somewhat of a stream of consciousness as I read, so please excuse any lack of coherence. When you talk about the bugs being significant blockers to the latest release I feel like that kind of issue isn't necessarily touched by moving to a shorter release cadence. In fact if we're unwilling to let certain fixes wait a release then it exacerbates the risk of slowing down a release. I'm not really sure what to do about this, other than adopting the mentality that fixes might not make the major release and will have to come in a point upgrade if they can't be merged to the release branch in time. Regarding the benefits of an abbreviated release cycle, we see it quite a lot in the rust community. There's a good amount of community involvement with the new releases, and new features are hotly anticipated as they often occur on a timescale where the enthusiasm is still there. I also feel, though this is purely anecdotal, that the more agile release schedule encourages community contributions as the tangible benefits of contributor work can be realised much more quickly. The number of RFCs in discussion at the moment is evidence of that, I feel. It's not all sunny, however, as having so many rapid releases means that it's sometimes difficult to rally the community around certain releases and feature sets. This is perhaps less of an issue due to the maturity of GHC and its ecosystem, but, like you say, it's important to find a good trade-off between release cadence and stability. Personally, I think Rust's cadence is a touch too short. On a related note, there's a 'checkpoints' initiative to build rallying releases that represent significant milestones in development [1]. This is, however, also tied into Rust's stability story, so only parts of it are relevant to GHC. In terms of automated tooling, I think there is significant benefit from it. Again, using rust as an example, there is cargobomb [2], a significant automated testing initiative that both combines packages on Cargo, and runs their test suites. I feel that a combination of the Stackage LTS and Nightly releases would provide a well-curated subset of Hackage that could possibly be used in a similar fashion. This hits on your item (b). Regarding your questions: - In comparison to rust it can feel like there's significant delay in being able to really use GHC's newest features. I feel like this delay can hinder adoption of the features as much of the enthusiasm for them has died down by the time they're properly available. - With the advent of tools such as `stack`, the compiler upgrade process has almost become trivial. While not everyone uses it, it requires no more work than upgrading to a new LTS release and running `stack setup`. Nevertheless, I could imagine four upgrades a year still being okay if it was manual. - The three release policy is an interesting case as the question of changing it really comes down to how we view the GHC stability story. Personally, I think we want to target a time-period of stability, rather than a number of releases. Whether that time period is 1.5 years (assuming a six-month release cadence), or 3 years (rounding the current release cadence) seems like a totally independent discussion to me. - I think I've covered incentives to contribute in my discussion of Rust above. I hope that's useful! Best, _ara [1] https://github.com/rust-lang/rfcs/pull/2052 [2] https://github.com/rust-lang-nursery/cargobomb > On 1 Aug 2017, at 03:19, Ben Gamari wrote: > > > Hello everyone, > > I just posted a pair of posts on the GHC blog [1,2] laying out some > thoughts on the GHC release cycle timing [1] and how this relates to the > in-progress Jenkins build infrastructure [2]. When you have a some time > feel free to give them a read and comment (either here or on the Reddit > thread [3]). > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule > [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci > [3] > https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC release timing and future build infrastructure
Glad I could provide some useful thoughts! > You are to some extent correct; an unwillingness to release before major > (for some definition of "major") bugs are fixed will inevitably lead to > slips. However, I think a faster release cycle will make it easier to > accept releases with such bugs (at least in the case of non-regressions). I definitely agree that a shortened release cadence would help with the reduction of release blockers by making som things more acceptable. I think this would be one of the major benefits of shortening the release cycle. > I agree that Rust is a bit extreme. Even with ideal tooling I don't > think that GHC could manage the cadence maintained by Rust, nor do I > think we should. The language is simply at a much different point in its > evolution. Their strong adherence to stability certainly also helps. I'm definitely with you here. I think that a 3-month release cycle is the shortest that would work for GHC, but that would require a perfect set of tooling which we don't quite have yet. Your originally proposed six months sounds great to me, and I don't see an reason why it couldn't be altered further down the line if it wasn't quite working. > Indeed tools have improved remarkably in the Haskell community over the > past few years. However, I feel like a word like "trivial" may be a bit > strong here. Afterall, library authors still need to follow changes in > core libraries (e.g. template-haskell, ghc-prim, and ghc itself). This > does require effort, although perhaps on the part of a smaller number of > people. Trivial was perhaps somewhat overstating the current state of the ecosystem, yes. I nevertheless see `stack` as a huge boon for easing adoption of new compiler versions (and hence new language features/extensions). _ara > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC release timing and future build infrastructure
I definitely agree with what you're saying around some of the features that require external support such as backpack. I think my statement was focused more on new language features that don't require additional support, as with stack getting access to those is as simple as hopping on the latest nightly release. On Thu, Aug 3, 2017 at 9:38 AM, Herbert Valerio Riedel wrote: > Hi! > > On 2017-08-03 at 08:41:59 +0200, Ara Adkins wrote: > > [...] > > > I nevertheless see `stack` as a huge boon for easing adoption of new > > compiler versions (and hence new language features/extensions). > > Since I totally disagree about Stack being beneficial to the quick > adoption of new features, would you care to elaborate what makes you > think that Stack was a "huge boon" in this particular context? > > Just to name one example where Stack has been lagging behind Cabal for > several months already: Support for Backpack or convenience libraries -- > there's already a handful of packages on Hackage which Stack (and > consequently Stackage) cannot install due to this. Being slow to adopt > new features IMO makes totally sense for Stack, as it's target audience > is practicioners who value stability, "reproducibility" and "long term > support", so it's actually a good thing that Stack stays behind until we > iron out issues with new bleeding edge features and Stack(age) adopts > them only when they're officially released and deemed ready for Stack's > target audience. > > -- hvr > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Alex install failure
NFS can be pretty dodgy with transient files due to latency. Sometimes the delete takes appreciable time after the command is issued so the lock file might just be persisting. I’d try installing into a cabal sandbox on a local drive and see if the same issue crops up. _ara > On 18 Aug 2017, at 23:43, Simon Peyton Jones wrote: > > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. So > what? > > Simon > > | -Original Message- > | From: Ben Gamari [mailto:b...@smart-cactus.org] > | Sent: 18 August 2017 13:05 > | To: Simon Peyton Jones ; ghc-devs | d...@haskell.org> > | Subject: Re: Alex install failure > | > | Simon Peyton Jones via ghc-devs writes: > | > | > Friends > | > I'm trying to update my installation of alex, on Unix (Ubuntu). But I > | > get the dump below It's complaining about a lock file being an invalid > | argument (see highlight below). > | > If I manually remove the file I get past that, it successfully > | > installs tf-random, but the same thing happens on the next package. So > | > I can install packages one at a time, but that's silly. > | > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > | > | Cheers, > | > | - Ben > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Alex install failure
I don’t disagree in the slightest! It’s just an easy way to find out if that is the cause of what you’re seeing or if it’s something deeper. For what it’s worth I’ve tried to replicate this on NFS to no avail, but it’s not like the mount I was using was under much load. _ara > On 19 Aug 2017, at 00:37, Simon Peyton Jones wrote: > > Maybe so, but it's really not a good experience for GHC/Cabal users. If > aptget did this, people would bleat loudly. > > Simon > > | -Original Message- > | From: Ara Adkins [mailto:m...@ara.io] > | Sent: 19 August 2017 00:07 > | To: Simon Peyton Jones > | Cc: Ben Gamari ; ghc-devs > | Subject: Re: Alex install failure > | > | [You don't often get email from m...@ara.io. Learn why this is important at > | http://aka.ms/LearnAboutSenderIdentification.] > | > | NFS can be pretty dodgy with transient files due to latency. Sometimes > | the delete takes appreciable time after the command is issued so the lock > | file might just be persisting. I’d try installing into a cabal sandbox on > | a local drive and see if the same issue crops up. > | > | _ara > | > | > On 18 Aug 2017, at 23:43, Simon Peyton Jones > | wrote: > | > > | > | Hmm. Here's a shot in the dark: is home home directory mounted via > | > | NFS by any chance? > | > > | > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. > | So what? > | > > | > Simon > | > > | > | -Original Message- > | > | From: Ben Gamari [mailto:b...@smart-cactus.org] > | > | Sent: 18 August 2017 13:05 > | > | To: Simon Peyton Jones ; ghc-devs | > | d...@haskell.org> > | > | Subject: Re: Alex install failure > | > | > | > | Simon Peyton Jones via ghc-devs writes: > | > | > | > | > Friends > | > | > I'm trying to update my installation of alex, on Unix (Ubuntu). > | > | > But I get the dump below It's complaining about a lock file being > | > | > an invalid > | > | argument (see highlight below). > | > | > If I manually remove the file I get past that, it successfully > | > | > installs tf-random, but the same thing happens on the next > | > | > package. So I can install packages one at a time, but that's silly. > | > | > | > | Hmm. Here's a shot in the dark: is home home directory mounted via > | > | NFS by any chance? > | > | > | > | Cheers, > | > | > | > | - Ben > | > > | > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: dll-split
With a hit like that I think it should at least be highly publicised that it can cause huge hits to compilation time. I would support bundling the executable if it has a compatible license. _ara On Wed, Aug 30, 2017 at 3:19 PM, Ryan Scott wrote: > Thanks for putting so much effort into this work, Tamar! > > > When I do turn it on, by default you will get a large ~45min hit in > compile time. > > Yikes, that's really bad! Bad enough that I have to wonder: would it > be worth including genlib among the other executables that we bundle > with GHC? Fortunately, us GHC developers have the foresight to know > that we should install genlib, but I imagine less informed Windows > users probably won't get the memo and will start to wonder why > compilation became so slow all of a sudden. > > Ryan S. > ___ > 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: dll-split
That’s a very good point, and should be a good solution for now. _ara > On 30 Aug 2017, at 18:28, Phyx wrote: > > That's certainly a possibility, though note that this is only an issue for > compiling stage2, not end user programs. > Since it's only for compiling ghc we don't have to include it in the bindist > so license would be less of an issue I think. > > I'll modify the scripts to pull it automatically when I submit the rest of > the patches. > > Thanks, > Tamar > >> On Wed, Aug 30, 2017 at 3:25 PM Ara Adkins wrote: >> With a hit like that I think it should at least be highly publicised that it >> can cause huge hits to compilation time. I would support bundling the >> executable if it has a compatible license. >> >> _ara >> >>> On Wed, Aug 30, 2017 at 3:19 PM, Ryan Scott wrote: >>> Thanks for putting so much effort into this work, Tamar! >>> >>> > When I do turn it on, by default you will get a large ~45min hit in >>> > compile time. >>> >>> Yikes, that's really bad! Bad enough that I have to wonder: would it >>> be worth including genlib among the other executables that we bundle >>> with GHC? Fortunately, us GHC developers have the foresight to know >>> that we should install genlib, but I imagine less informed Windows >>> users probably won't get the memo and will start to wonder why >>> compilation became so slow all of a sudden. >>> >>> Ryan S. >>> ___ >>> 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC staus
I’m definitely interested in hearing more about cross compilation for iOS. Might actually make an idea I’ve had brewing into something feasible! _ara > On 4 Sep 2017, at 11:16, Manuel M T Chakravarty wrote: > > +1 for a lighting talk on that! (You can tell the organisers that ;) > > Also, we should make sure to meet and talk about cross-compilation and GHC > for iOS :) > > Manuel > >> Moritz Angermann : >> >> Hi, >> >> not sure if this is noteworthy: >> >> The following is or will hopefully make(*) it >> into 8.4 as well >> >> - (1) iserv-remote (run iserv on a remote device over the network) >> - (2) arm / aarch64 linker for elf and mach-o >> - (3*) `-staticlib` support for Linux and BSD derivatives (was darwin only): >> - (4*) `-llvmng` new llvm bitcode code gen >> - (5*) refactored llvm pipeline >> >> This essentially is all part of making GHC natively >> support cross compiling (including support for Template Haskell) to >> android/iOS/RaspberryPi. >> >> I hope to give a lighting talk around those, if I get a slot. >> >> Cheers, >> Moritz >> >> Sent from my iPhone >> >>> On 4 Sep 2017, at 8:01 AM, Iavor Diatchki wrote: >>> >>> Hello, >>> >>> Trevor Elliott and I have been slowly working on implementing Simon M's >>> "Mutable Constructor Fields" proposal [1]. >>> >>> The current state of the code is here: >>> https://github.com/yav/ghc/tree/wip/mutable-fields >>> >>> I am not sure if this would be ready in time for 8.4 as I don't know what >>> the time-line looks like, and also, the actual proposal is still in the >>> process of being reviewed by the GHC committee. >>> >>> -Iavor >>> >>> [1] >>> https://github.com/simonmar/ghc-proposals/blob/mutable-fields/proposals/-mutable-fields.rst >>> >>> >>> On Sun, Sep 3, 2017 at 2:15 PM Simon Peyton Jones via ghc-devs wrote: Ben, Simon, and ghc-devs I have to write slides for the GHC status talk in the Haskell Implementor’s meeting. Usually we have Current status (current release) What’s cooking for the next release GHC community comments As background we have Our Apr 17 status page Our 8.2 release notes Our 8.4 status page What would you put under (1-3)? Anything you’d like to see highlighted? 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 >> ___ >> 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: A newcomer: how to start
Hey Sergey, I’d honestly head straight for the GHC newcomers guide [0]! Once you’re familiar with all of that just head for Trac and look for the low hanging fruit tasks! Most importantly, don’t forget to ask questions! Nobody here bites! Best, _ara [0] https://ghc.haskell.org/trac/ghc/wiki/Newcomers > On 5 Sep 2017, at 13:42, Sergey Bykov wrote: > > Hi, > > my name is Sergey and I'm recently joined to this mailing list. I would like > to help GHC's community and start contributing to the GHC project. Could > someone recommend a few tasks, which seems to be suitable for a beginner? > > About myself: > > I'm pretty experienced Research Scientist/Software Developer in such areas > like discrete optimization and machine learning. > > > Thanks in advance! > > ___ > 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: A type checker plugin for row types
Just given this a read! It looks like you’ve put a fantastic amount of effort into this so far, and I can certainly see how it’s finding its legs! I’m very much looking forward to seeing this develop further. I can definitely foresee some uses for polykinded column types, and the possibility for named arguments is certainly interesting (though I have some concerns about performance — though none are relevant at such an early stage). Unfortunately I don’t think I can answer any of the questions that I spotted on my read-through. Again, I’m looking forward to seeing this develop, and the naming of `coxswain` and `sculls` gave me a giggle. _ara > On 10 Sep 2017, at 23:24, Nicolas Frisby wrote: > > Hi all. I've been spending my free time for the last couple months on a type > checker plugin for row types. The free time waxes and wanes; sending an email > like this one was my primary goal for the past couple weeks. > > At the very least, I hoped this project would let me finally get some hands > on experience with OutsideIn. And I definitely have. But I've also made more > progress than I anticipated, and I think the plugin is starting to have legs! > > I haven't uploaded the code yet to github -- it's not quite ready to share. > But I did do a write up on the dev wiki. > > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain > > I would really appreciate and questions, comments, and --- boy, oh boy --- > answers. > > I hope to upload within a week or so, and I'll update that wiki page and > reply to this email when I do. > > Thanks very much. -Nick > > P.S. -- I've CC'd and BCC'd people who I anticipate would be specifically > interested in this (e.g. plugins, row types, etc). Please feel free to > forward to others that come to mind; I know some inboxes abjectly can't > afford default list traffic. > > P.P.S. -- One hold up for the upload is: which license? I intend to release > under BSD3, mainly to match GHC since one ideal scenario would involve being > packaged with/integrated into GHC. But my brief recent research suggests that > the Apache license might be more conducive to eventual widespread adoption. > If you'd be willing to advise or even just refer me to other write ups, > please feel free to email me directly or to start a separate thread on a more > appropriate distribution list (CC'ing me, please). Thanks again. > ___ > 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: A type checker plugin for row types
Glad I could be of help! I just gave it a read and that generated core is much
better than I expected. I’d still have some concerns regarding certain uses
(e.g. named arguments) having more performance overhead than hoped, but at this
stage it’s far better than I would’ve initially thought!
Definitely a useful addition to the wiki page.
_ara
> On 10 Sep 2017, at 23:58, Nicolas Frisby wrote:
>
> Whoops! I forgot about that section of my draft. I added a little blurb
> ("Performance?") Thanks Ara!
>
>
>
>> On Sun, Sep 10, 2017 at 3:41 PM Ara Adkins wrote:
>> Just given this a read!
>>
>> It looks like you’ve put a fantastic amount of effort into this so far, and
>> I can certainly see how it’s finding its legs! I’m very much looking forward
>> to seeing this develop further. I can definitely foresee some uses for
>> polykinded column types, and the possibility for named arguments is
>> certainly interesting (though I have some concerns about performance —
>> though none are relevant at such an early stage).
>>
>> Unfortunately I don’t think I can answer any of the questions that I spotted
>> on my read-through.
>>
>> Again, I’m looking forward to seeing this develop, and the naming of
>> `coxswain` and `sculls` gave me a giggle.
>>
>> _ara
>>
>>> On 10 Sep 2017, at 23:24, Nicolas Frisby wrote:
>>>
>>> Hi all. I've been spending my free time for the last couple months on a
>>> type checker plugin for row types. The free time waxes and wanes; sending
>>> an email like this one was my primary goal for the past couple weeks.
>>>
>>> At the very least, I hoped this project would let me finally get some hands
>>> on experience with OutsideIn. And I definitely have. But I've also made
>>> more progress than I anticipated, and I think the plugin is starting to
>>> have legs!
>>>
>>> I haven't uploaded the code yet to github -- it's not quite ready to share.
>>> But I did do a write up on the dev wiki.
>>>
>>>
>>> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain
>>>
>>> I would really appreciate and questions, comments, and --- boy, oh boy ---
>>> answers.
>>>
>>> I hope to upload within a week or so, and I'll update that wiki page and
>>> reply to this email when I do.
>>>
>>> Thanks very much. -Nick
>>>
>>> P.S. -- I've CC'd and BCC'd people who I anticipate would be specifically
>>> interested in this (e.g. plugins, row types, etc). Please feel free to
>>> forward to others that come to mind; I know some inboxes abjectly can't
>>> afford default list traffic.
>>>
>>> P.P.S. -- One hold up for the upload is: which license? I intend to release
>>> under BSD3, mainly to match GHC since one ideal scenario would involve
>>> being packaged with/integrated into GHC. But my brief recent research
>>> suggests that the Apache license might be more conducive to eventual
>>> widespread adoption. If you'd be willing to advise or even just refer me to
>>> other write ups, please feel free to email me directly or to start a
>>> separate thread on a more appropriate distribution list (CC'ing me,
>>> please). Thanks again.
>>
>>> ___
>>> 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: A type checker plugin for row types
Excellent! I've very much been looking forward to having a look at the code for this! On Sat, Sep 16, 2017 at 10:27 PM, Nicolas Frisby wrote: > I've uploaded the code to GitHub. > > https://github.com/nfrisby/coxswain > > I went with a BSD3 licence. > > It's still very much a work in progress, so I only recommend using it for > experimentation for now. > > Thanks. -Nick > > > On Sun, Sep 10, 2017 at 3:24 PM Nicolas Frisby > wrote: > >> Hi all. I've been spending my free time for the last couple months on a >> type checker plugin for row types. The free time waxes and wanes; sending >> an email like this one was my primary goal for the past couple weeks. >> >> At the very least, I hoped this project would let me finally get some >> hands on experience with OutsideIn. And I definitely have. But I've also >> made more progress than I anticipated, and I think the plugin is starting >> to have legs! >> >> I haven't uploaded the code yet to github -- it's not quite ready to >> share. But I did do a write up on the dev wiki. >> >> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/ >> RowTypes/Coxswain >> >> I would really appreciate and questions, comments, and --- boy, oh boy >> --- answers. >> >> I hope to upload within a week or so, and I'll update that wiki page and >> reply to this email when I do. >> >> Thanks very much. -Nick >> >> P.S. -- I've CC'd and BCC'd people who I anticipate would be specifically >> interested in this (e.g. plugins, row types, etc). Please feel free to >> forward to others that come to mind; I know some inboxes abjectly can't >> afford default list traffic. >> >> P.P.S. -- One hold up for the upload is: which license? I intend to >> release under BSD3, mainly to match GHC since one ideal scenario would >> involve being packaged with/integrated into GHC. But my brief recent >> research suggests that the Apache license might be more conducive to >> eventual widespread adoption. If you'd be willing to advise or even just >> refer me to other write ups, please feel free to email me directly or to >> start a separate thread on a more appropriate distribution list (CC'ing me, >> please). Thanks again. >> > > ___ > 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: Review of CONTRIBUTORS.md
Hey Ben, Looks good to me for the most part! I think that you should include a link to the Newcomers page [1] as a whole, even though it has some overlap with the quick start guide and you’ve included a link to the ‘Finding a Ticket’ subsection therein. I also think that a few more pointers on what is hoped for in a review (under ‘Reviewing Patches’) could be helpful for those looking to get involved! Code review styles and expectations can vary greatly, so some more info here would be good. Best, _ara [1] https://ghc.haskell.org/trac/ghc/wiki/Newcomers > On 26 Sep 2017, at 21:58, Ben Gamari wrote: > > Hello everyone, > > Today I sat down and wrote a CONTRIBUTORS.md document for the ghc > repository. This is recommended by GitHub to ensure that contributors > can easily discover the first steps to contributing to the project. > Moreover, it provided a nice blank slate to summarize the existing > contributor documentation. > > It would be greatly appreciated if you could give it [1] a read-through > and leave your feedback. > > Cheers, > > - Ben > > > [1] https://phabricator.haskell.org/D4037 >https://github.com/bgamari/ghc/blob/contributing/CONTRIBUTING.md > ___ > 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: Review of CONTRIBUTORS.md
Hi Ben, No further suggestions, but the link to the newcomers page is broken, and there is a typo towards the end of the ‘Writing Patches’ section: ‘relative unconversial’ -> ‘relatively uncontroversial’. Sorry for the lack of line numbers but I can’t work out how to view the raw file on my phone! _ara > On 28 Sep 2017, at 01:33, Ben Gamari wrote: > > Ara Adkins writes: > >> Hey Ben, >> >> Looks good to me for the most part! I think that you should include a >> link to the Newcomers page [1] as a whole, even though it has some >> overlap with the quick start guide and you’ve included a link to the >> ‘Finding a Ticket’ subsection therein. >> >> I also think that a few more pointers on what is hoped for in a review >> (under ‘Reviewing Patches’) could be helpful for those looking to get >> involved! Code review styles and expectations can vary greatly, so >> some more info here would be good. >> > Thanks Ara! I've tried to address both of these in the patch. Do let me > know if you have further suggestions. > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for @. (31515fa)
It’s been one heck of a day with these coming in. It does seem to have stopped now. _ara > On 27 Oct 2017, at 22:58, Simon Peyton Jones via ghc-devs > wrote: > > yes I think it's stopped. I'' remove my junk-mail rule > > | -Original Message- > | From: Ben Gamari [mailto:b...@smart-cactus.org] > | Sent: 27 October 2017 19:44 > | To: Simon Peyton Jones ; ghc-devs@haskell.org > | Subject: Re: FW: [commit: ghc] wip/nfs-locking: Use conventional > | whitespacing for @. (31515fa) > | > | Simon Peyton Jones via ghc-devs writes: > | > | > I've received 1500 of these commit messages overnight, and another > | arrives every few seconds. Are they likely to stop soon? > | > > | Oh dear, this looks like an unfortunate consequence of my pushing a > | branch with the Hadrian history. Have they stopped yet? > | > | Cheers, > | > | - Ben > ___ > 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
Commit Notifications Flood
Is anyone else getting an absolute flood of commit emails related to haddock? I remember this happening a little while back with the hadrian merge into the GHC tree. Best, _ara ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Commit Notifications Flood
I've put a redirect rule on them for now, but given that this is the second time that it's happened (as far as I know), is it possible to modify the way in which the commit hook sends notifications for new branches with a significant history? I don't really know much about the exact message generation process, but perhaps it is possible to provide a digest when pushing a new branch. Something that lists the branch name and the number of commits, for example. Best, _ara On Mon, Nov 20, 2017 at 11:01 PM, Simon Peyton Jones wrote: > I’m getting them too ☹ > > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Ara > Adkins > *Sent:* 20 November 2017 21:07 > *To:* GHC developers > *Subject:* Commit Notifications Flood > > > > Is anyone else getting an absolute flood of commit emails related to > haddock? I remember this happening a little while back with the hadrian > merge into the GHC tree. > > > > Best, > > _ara > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Moving hadrian to submodule
Sounds good! Hopefully this doesn’t cause a flood of commit messages. _ara > On 8 Dec 2017, at 18:50, Ben Gamari wrote: > > Hello everyone, > > A bit over a month ago we merged hadrian into the ghc tree as a subtree. > Unfortunately, those working on Hadrian have found the subtree mechanism > to provide a rather poor developer experience. Consequently, today I > will be ripping out the subtree and replacing it with a submodule. > > After pulling the commit performing this change you will likely need to > do the following to emplace the new submodule, > >$ git submodule update --init >$ git -C hadrian checkout . > > Cheers, > > - Ben > ___ > 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
Failure to Build
Hey Devs, I'm having trouble building the head of the ghc-8.6 branch (`26a7f850d1`) on my Arch Linux machine. The essence of the error is this as follows, though the full result of make (to the point of error) is attached. ``` Configuring template-haskell-2.14.0.0... ghc-cabal: Encountered missing dependencies: ghc-boot-th ==8.6.* && ==8.7 ``` The output of configure is as follows: ``` -- Configure completed successfully. Building GHC version : 8.7.20180730 Git commit id : 26a7f850d15b91ad68d1e28d467faba00bb79144 Build platform: x86_64-unknown-linux Host platform : x86_64-unknown-linux Target platform : x86_64-unknown-linux Bootstrapping using : /usr/bin/ghc which is version : 8.4.3 Using (for bootstrapping) : gcc Using gcc : gcc which is version : 8.1.1 Building a cross compiler : NO Unregisterised: NO hs-cpp : gcc hs-cpp-flags : -E -undef -traditional ar : ar ld : ld.gold nm : nm libtool : libtool objdump : objdump ranlib : ranlib windres : dllwrap : genlib : Happy: /home/ara/.local/bin/happy (1.19.9) Alex : /usr/bin/alex (3.2.4) Perl : /usr/bin/perl sphinx-build : /usr/bin/sphinx-build xelatex : /usr/bin/xelatex Using LLVM tools clang : clang llc : opt : HsColour : /usr/bin/HsColour Tools to build Sphinx HTML documentation available: YES Tools to build Sphinx PDF documentation available: YES -- ``` Any help would be most appreciated. Best, _ara + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cp -p mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk + test -f compiler/ghc.cabal.old + cp -p compiler/ghc.cabal compiler/ghc.cabal.old touch -r compiler/ghc.cabal.old compiler/ghc.cabal ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds mkdir -p inplace/bin mkdir -p inplace/lib "rm" -f inplace/bin/mkdirhier echo '#!/bin/sh' >> inplace/bin/mkdirhier cat utils/mkdirhier/mkdirhier.sh >> inplace/bin/mkdirhier chmod +x inplace/bin/mkdirhier "inplace/bin/mkdirhier" utils/ghc-cabal/dist/build/tmp//. "inplace/bin/mkdirhier" bootstrapping/. "inplace/bin/mkdirhier" compiler/stage1/build//. "inplace/bin/mkdirhier" utils/ghc-pkg/dist/build//. "/usr/bin/ghc" -O -H64m -Wall \ -optc-Wall -optc-fno-stack-protector \ \ -hide-all-packages \ -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package unix \ --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ -DCABAL_VERSION=2,3,0,0 \ -DCABAL_PARSEC \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ libraries/Cabal/Cabal/Distribution/Parsec/Lexer.hs \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src \ -ilibraries/filepath \ -ilibraries/hpc \ -ilibraries/mtl \ -ilibraries/text \ libraries/text/cbits/cbits.c \ -Ilibraries/text/include \ -ilibraries/parsec/src \ \ "rm" -f compiler/stage1/build/Config.hs "rm" -f utils/ghc-pkg/dist/build/Version.hs Creating compiler/stage1/build/Config.hs ... echo "module Version where">> utils/ghc-pkg/dist/build/Version.hs echo "version, targetOS, targetARCH :: String" >> utils/ghc-pkg/dist/build/Version.hs echo "version= \"8.7.20180730\"" >> utils/ghc-pkg/dist/build/Version.hs echo "targetOS = \"linux\"">> utils/ghc-pkg/dist/build/Version.hs echo "targetARCH = \"x86_64\"" >> utils/ghc-pkg/dist/build/Version.hs done. [ 1 of 271] Compiling Control.Monad.Cont.Class ( libraries/mtl/Control/Monad/Cont/Class.hs, bootstrapping/Control/Monad/Cont/Class.o ) [ 2 of 271] Compiling Control.Monad.Error.Class ( libraries/mtl/Control/Monad/Error/Class.hs, bootstrapping/Control/Monad/Error/Class.o ) [ 3 of 271] Compiling Control.Monad.Identity ( libraries/mtl/Control/Monad/Identity.hs, bootstrapping/Control/Monad/Identity.o ) [ 4 of 271] Compiling Control.Monad.Reader.Class ( libraries/mtl/Control/Monad/Reader/Class.hs, bootstrapping/Control/Monad/Reader/Class.o ) [ 5 of 271] Compiling Control.Monad.State.Class ( libraries/mtl/Control/Monad/State/Class.hs, bootstrapping/Control/Monad/State/Class.o ) [ 6 of 271] Compiling Control.Monad.Trans ( libraries/mtl/Control/Monad/Trans.hs, bo
Re: Failure to Build
Thanks all for the insight so far! Doing that has got me further along in the build, but it is still failing. Amongst the output of `make` it seems that the offending error is as follows: ``` happy: /home/ara/.stack/snapshots/x86_64-linux-tinfo6-nopie/nightly-2018-02-20/8.2.2/share/x86_64-linux-ghc-8.2.2/happy-1.19.9/HappyTemplate-arrays-coerce: openFile: does not exist (No such file or directory) make[1]: *** [utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/build/Parser.hs] Error 1 make[1]: *** Waiting for unfinished jobs ``` Any further thoughts appreciated, as always! <3 Best, _ara On Tue, 31 Jul 2018 at 16:06, Ben Gamari wrote: > Sylvain Henry writes: > > > When something like this fails, I usually do: > > > > make maintainer-clean > > git submodule update --init > > ./boot > > ./configure > > make -j > > > Right, it sounds like there are some stale files. I'd bet this fixes it. > > Cheers, > > - Ben > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Failure to Build
Hi Ben, That was spot on! I guess there's something wrong with the stack install of happy - using the one installed from the system package manager worked perfectly. Best, _ara On Tue, 31 Jul 2018 at 16:56, Ben Gamari wrote: > Ara Adkins writes: > > > Thanks all for the insight so far! > > > > Doing that has got me further along in the build, but it is still > failing. > > Amongst the output of `make` it seems that the offending error is as > > follows: > > ``` > > happy: > > > /home/ara/.stack/snapshots/x86_64-linux-tinfo6-nopie/nightly-2018-02-20/8.2.2/share/x86_64-linux-ghc-8.2.2/happy-1.19.9/HappyTemplate-arrays-coerce: > > openFile: does not exist (No such file or directory) > > > It looks like your happy installation is incomplete. Is it possible you > deleted that file? If not, it sounds like a stack issue. Perhaps try > installing happy with cabal or your system's package manager. > > Cheers, > > - Ben > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Starting hacking on GHC
Hi Andrew, Welcome! Before I go suggesting particular tickets, I just wanted to make sure that you've taken a look at this section https://ghc.haskell.org/trac/ghc/wiki/Newcomers#Findingaticket of the Newcomers page! It lists a decent set of tickets deemed workable for newcomers. This doesn't, of course, mean that you have to go it alone. In my experience people are always happy to help! Best, _ara On Mon, 13 Aug 2018 at 14:57, Andrew Rmnsky wrote: > > Hello everyone! I would like to contribute to GHC, but I don't know where > to start (I have built it already from the source). I'd be happy if someone > gave me a piece of advice on what task I should pick for the beginning. > > A few words about my background: > CS student, 4-th grade, have some experience with Haskell (I had a course > on Haskell in my university where I studied some theory like Monoids, > Functors, Applicatives Monads, Monad Transformers, Lens, basics of parallel > and concurrent programming in Haskell and I have solved some algorithmic > problems. I also practiced developing small web-apps with Haskell, using > warp, aeson, postgresql-simple and some other libraries. > > Looking forward for your replies. Thank you in advance! > > Andrew Romanovsky. > > ___ > 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
Using GHC Core as a Language Target
Hey All, I was chatting to SPJ about the possibility of using GHC Core + the rest of the GHC compilation pipeline as a target for a functional language, and he mentioned that asking here would likely be more productive when it comes to the GHC API. I'm wondering where the best place would be for me to look in the API for building core expressions, and also whether it is possible to trigger the GHC code-generation pipeline from the core stage onwards. Best, Ara ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Using GHC Core as a Language Target
Heya, Those are exactly the kind of pointers I was hoping for. Thanks Iavor. I’m sure I’ll have more questions with time, but that’s a great starting point. _ara > On 25 Oct 2018, at 19:20, Iavor Diatchki wrote: > > Hello, > > I have not done what you are asking, but here is how I'd approach the > problem. > > 1. Assuming you already have some Core, you'd have to figure out how to > include it with the rest of the GHC pipeline: > * A lot of the code that glues everything together is in `compiler/main`. > Modules of interest seem to be `DriverPipeline`, `HscMain`, and > `PipelineMoand` > * A quick looks suggests that maybe you want to call `hscGenHardCode` in > `HscMain`, with your core program inside the `CgGuts` argument. > * Exactly how you setup things probably depends on how much of the rest > of the Haskell ecosystem you are trying to integrate with (separate > compilation, avoiding recompilation, support for packages, etc.) > > 2. The syntax for Core is in `compiler/coreSyn`, with the basic AST being in > module `CoreSyn`. Module `MkCore` has a lot of helpers for working with > core syntax. > > 3. The "desugarer" (in `compiler/deSugar`) is the GHC phase that translates > the front end syntax (hsSyn) into core, so that should have lots of examples > of how to generate core. > > Cheers, > -Iavor > > > > > > > >> On Mon, Oct 22, 2018 at 1:46 AM Ara Adkins wrote: >> Hey All, >> >> I was chatting to SPJ about the possibility of using GHC Core + the rest of >> the GHC compilation pipeline as a target for a functional language, and he >> mentioned that asking here would likely be more productive when it comes to >> the GHC API. >> >> I'm wondering where the best place would be for me to look in the API for >> building core expressions, and also whether it is possible to trigger the >> GHC code-generation pipeline from the core stage onwards. >> >> Best, >> Ara >> ___ >> 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: Using GHC Core as a Language Target
That’s a brilliant resource! Thanks so much for the links. _ara > On 29 Oct 2018, at 19:11, Csaba Hruska wrote: > > There is also a nice intro blog post about GHC internals with an example how > to compile a custom constructed module AST. > Dive into GHC: Pipeline > Dive into GHC: Intermediate Forms > Dive into GHC: Targeting Core > Cheers, > Csaba Hruska > >> On Thu, Oct 25, 2018 at 8:51 PM Ara Adkins wrote: >> Heya, >> >> Those are exactly the kind of pointers I was hoping for. Thanks Iavor. >> >> I’m sure I’ll have more questions with time, but that’s a great starting >> point. >> >> _ara >> >>> On 25 Oct 2018, at 19:20, Iavor Diatchki wrote: >>> >>> Hello, >>> >>> I have not done what you are asking, but here is how I'd approach the >>> problem. >>> >>> 1. Assuming you already have some Core, you'd have to figure out how to >>> include it with the rest of the GHC pipeline: >>> * A lot of the code that glues everything together is in >>> `compiler/main`. Modules of interest seem to be `DriverPipeline`, >>> `HscMain`, and `PipelineMoand` >>> * A quick looks suggests that maybe you want to call `hscGenHardCode` >>> in `HscMain`, with your core program inside the `CgGuts` argument. >>> * Exactly how you setup things probably depends on how much of the rest >>> of the Haskell ecosystem you are trying to integrate with (separate >>> compilation, avoiding recompilation, support for packages, etc.) >>> >>> 2. The syntax for Core is in `compiler/coreSyn`, with the basic AST being >>> in module `CoreSyn`. Module `MkCore` has a lot of helpers for working >>> with core syntax. >>> >>> 3. The "desugarer" (in `compiler/deSugar`) is the GHC phase that translates >>> the front end syntax (hsSyn) into core, so that should have lots of >>> examples of how to generate core. >>> >>> Cheers, >>> -Iavor >>> >>> >>> >>> >>> >>> >>> >>>> On Mon, Oct 22, 2018 at 1:46 AM Ara Adkins wrote: >>>> Hey All, >>>> >>>> I was chatting to SPJ about the possibility of using GHC Core + the rest >>>> of the GHC compilation pipeline as a target for a functional language, and >>>> he mentioned that asking here would likely be more productive when it >>>> comes to the GHC API. >>>> >>>> I'm wondering where the best place would be for me to look in the API for >>>> building core expressions, and also whether it is possible to trigger the >>>> GHC code-generation pipeline from the core stage onwards. >>>> >>>> Best, >>>> Ara >>>> ___ >>>> 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [GHC DevOps Group] The future of Phabricator
Also as part of the silent bystander group, I would definitely be okay with a swap to GitLab. I don’t have anything particularly against Phab and Trac, but I recognise the reduction in general friction the swap would create. _ara > On 3 Nov 2018, at 13:38, Richard Eisenberg wrote: > > > >> On Nov 3, 2018, at 9:17 AM, Alan & Kim Zimmerman wrote: >> >> As part of the silent bystander grouping, I just want to voice a weak ok for >> switching to gitlab, > > +1 to this exact sentiment from me, and for the same reasons Alan voiced. I > have a horse in this race and care about the outcome, but don't have enough > of an informed opinion to really say anything of substance. I'm very grateful > to those who have informed opinions and will debate (and then implement) our > way into the future. > > Richard > ___ > 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
GitLab Migration
Hey All, Sorry for my confusion, but I'm a bit unclear as to when we're meant to start working against the GHC repo on the gitlab.haskell.org instance. I had in mind that the cutover was intended to be the 18th, but going on there it still appears as if it's mirrored from git.haskell.org. Can somebody clarify this for me? Best, _ara ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GitLab Migration
How curious! Some clarification would definitely be appreciated. _ara > On 20 Dec 2018, at 17:40, Gabor Greif wrote: > > (To: Ben added directly) > > Yes, https://gitlab.haskell.org/ghc/ghc still seems to mirror > https://:*@git.haskell.org/ghc, so the cutover is not complete > yet. > > OTOH, the Gitlab instance allowed me to merge a request (which did not > work yesterday), so /something/ has changed. The interesting > consequence is now that > https://gitlab.haskell.org/ghc/ghc fails to sync with its master. > > Another thing missing is to redirect the github mirror > (https://github.com/ghc/ghc), too. > > Cheers, > >Gabor > >> On 12/20/18, Ara Adkins wrote: >> Hey All, >> >> Sorry for my confusion, but I'm a bit unclear as to when we're meant to >> start working against the GHC repo on the gitlab.haskell.org instance. I >> had in mind that the cutover was intended to be the 18th, but going on >> there it still appears as if it's mirrored from git.haskell.org. Can >> somebody clarify this for me? >> >> Best, >> _ara >> ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GitLab Migration
Perfect. Thanks for the clarification Ben! _ara > On 21 Dec 2018, at 16:55, Ben Gamari wrote: > > Ara Adkins writes: > >> Hey All, >> >> Sorry for my confusion, but I'm a bit unclear as to when we're meant to >> start working against the GHC repo on the gitlab.haskell.org instance. I >> had in mind that the cutover was intended to be the 18th, but going on >> there it still appears as if it's mirrored from git.haskell.org. Can >> somebody clarify this for me? >> > Sorry for the confusion. I have been reluctant to formally announce the > cut-over until CI is green but this has taken a fair bit longer than > anticipated due to the long CI cycle time. Nevertheless people have > started submitting MRs against the GitLab instance and you are more than > welcome to do so. > > As far as the official upstream repository, indeed > gitlab.haskell.org/ghc/ghc is still mirroring git.haskell.org/ghc. This > will change when I formally announce the switchover. > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Welcome to GitLab!
Congrats to Ben and everybody involved! This has been a long time coming and I’m super excited to see what it means for GHC in the future! _ara On 27 Dec 2018, at 11:56, Matthew Pickering wrote: >> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >> "fast-forward without a merge commit" merge strategy. > > Are merge requests squashed before they are merged? > > It seems that the answer by default is no.. > https://gitlab.com/gitlab-org/gitlab-ce/issues/27956 > > and the reason being that upsteam prefers "Convention over > Configuration".. > https://about.gitlab.com/handbook/product/#convention-over-configuration > > However it seems that there is a per-mr option which can be checked if > you are diligent to do it for each MR. Some comments indicate that > it's possible to implement a webhook to change this behaviour. > > Matt > >> On Thu, Dec 27, 2018 at 6:28 AM Ben Gamari wrote: >> >> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official >> upstream GHC repository. Various introductory notes are >> discussed. Let me know if you have any trouble. >> >> Also, please do verify the correctness of the email address >> associated with your Trac account in the next few weeks. It will >> be used to map users when we transition Trac tickets to GitLab. >> >> >> >> Hello everyone, >> >> I am happy to announce that CI on GHC's GitLab instance [1] is now >> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be >> considered the official upstream repository of GHC. >> >> The rest of this email is meant to serve as a brief introduction and >> status update. It can also be viewed on the GitLab Wiki [2]. >> >> [1] https://gitlab.haskell.org/ >> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome >> >> >> # Getting started >> >> To get started on GitLab you will first want to either create a new account >> [1] or login with your GitHub credentials [2]. >> >> Once you have an account you should add an SSH key [3] so that you can push >> to your repositories. If you currently have commit rights to GHC notify me >> (Ben Gamari) of your user name so I can grant you similar rights in GitLab. >> >> >> [1] https://gitlab.haskell.org/users/sign_in >> [2] https://gitlab.haskell.org/users/auth/github >> [3] https://gitlab.haskell.org/profile/keys >> >> >> # Updating your development environment >> >> You can updated existing working directory (assuming the usual upstream >> remote name of `origin`) for the new upstream repository location by >> running the following: >> >>git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git >>git remote set-url --push origin g...@gitlab.haskell.org:ghc/ghc >> >> This is all that should be necessary; a quick `git pull origin master` >> should verify that everything is working as expected. >> >> >> # Continuous integration >> >> Continuous integration is now provided by GitLab's native continuous >> integration infrastructure. We currently test a variety of >> configurations, including many that neither Phabricator nor >> CircleCI/Appveyor previously tested (see [1] for an example run): >> >> * With the make build system: >>* x86_64/Linux on Fedora 27, Debian 8, and Debian 9 >>* i386/Linux on Debian 9 >>* aarch64/Linux on Debian 9 (currently broken due to a variety of >> issues) >>* x86_64/Windows >>* x86_64/Darwin >>* x86_64/Linux on Debian 9 in a few special configurations: >>* unregisterised (still a bit fragile due to #16085) >>* integer-simple >>* building GHC with -fllvm >> * With Hadrian: >>* x86_64/Linux on Debian 9 >>* x86_64/Windows (currently broken due to #15950) >> >> We also run a slightly larger set of jobs on a nightly basis. Note that >> binary distributions are saved from most builds and are available for >> download for a few weeks (we may put in place a longer retention policy >> for some builds in the future). >> >> There are admittedly a few kinks that we are still working out, >> particularly in the case of Windows (specifically the long build times >> seen on Windows). If you suspect you are seeing spurious build failures >> do let us know. >> >> To make the best use of our limited computational resources our CI >> builds occur in three stages: >> >> * lint: the style and correctness checkers which would previously be >> run by `arc lint` and `git push` >> >> * build: Debian 9 Linux x86_64 built with make and Hadrian >> >> * full-build: the remaining configurations >> >> If a build fails at an earlier phase no further phases will be run. >> >> >> [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568 >> >> >> # Structuring your merge request >> >> With the transition to GitLab GHC is moving to a model similar to that >> used by GitHub. If you have a Differential on Phabricator we will finish >> review there. However, please post new patches as merge requests on >> GitL
Re: Welcome to GitLab!
Along the lines of things needing to be adapted, are we moving the ghc-commits mailing list over to GL? _ara > On 27 Dec 2018, at 14:05, Gabor Greif wrote: > > Great work, Ben! > > Thanks for all the hard work setting up this CI. My hopes are high > that our contributions' quality and ease will go up. > > There seem to be a few loose ends that need to be wrapped up, like > redirect the mirroring of https://github.com/ghc/ghc/ towards GitLab > and possibly switch on mirroring for http://git.haskell.org/ghc.git . > Or should we just add a redirect? Should pull requests be blocked on the > former? > > Anyway some readmes need to be adapted for the new world order. > > Cheers, > >Gabor > >> On 12/27/18, Ara Adkins wrote: >> Congrats to Ben and everybody involved! This has been a long time coming and >> I’m super excited to see what it means for GHC in the future! >> >> _ara >> >> On 27 Dec 2018, at 11:56, Matthew Pickering >> wrote: >> >>>> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >>>> "fast-forward without a merge commit" merge strategy. >>> >>> Are merge requests squashed before they are merged? >>> >>> It seems that the answer by default is no.. >>> https://gitlab.com/gitlab-org/gitlab-ce/issues/27956 >>> >>> and the reason being that upsteam prefers "Convention over >>> Configuration".. >>> https://about.gitlab.com/handbook/product/#convention-over-configuration >>> >>> However it seems that there is a per-mr option which can be checked if >>> you are diligent to do it for each MR. Some comments indicate that >>> it's possible to implement a webhook to change this behaviour. >>> >>> Matt >>> >>>> On Thu, Dec 27, 2018 at 6:28 AM Ben Gamari wrote: >>>> >>>> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official >>>> upstream GHC repository. Various introductory notes are >>>> discussed. Let me know if you have any trouble. >>>> >>>> Also, please do verify the correctness of the email address >>>> associated with your Trac account in the next few weeks. It will >>>> be used to map users when we transition Trac tickets to GitLab. >>>> >>>> >>>> >>>> Hello everyone, >>>> >>>> I am happy to announce that CI on GHC's GitLab instance [1] is now >>>> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be >>>> considered the official upstream repository of GHC. >>>> >>>> The rest of this email is meant to serve as a brief introduction and >>>> status update. It can also be viewed on the GitLab Wiki [2]. >>>> >>>> [1] https://gitlab.haskell.org/ >>>> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome >>>> >>>> >>>> # Getting started >>>> >>>> To get started on GitLab you will first want to either create a new >>>> account >>>> [1] or login with your GitHub credentials [2]. >>>> >>>> Once you have an account you should add an SSH key [3] so that you can >>>> push >>>> to your repositories. If you currently have commit rights to GHC notify >>>> me >>>> (Ben Gamari) of your user name so I can grant you similar rights in >>>> GitLab. >>>> >>>> >>>> [1] https://gitlab.haskell.org/users/sign_in >>>> [2] https://gitlab.haskell.org/users/auth/github >>>> [3] https://gitlab.haskell.org/profile/keys >>>> >>>> >>>> # Updating your development environment >>>> >>>> You can updated existing working directory (assuming the usual upstream >>>> remote name of `origin`) for the new upstream repository location by >>>> running the following: >>>> >>>> git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git >>>> git remote set-url --push origin g...@gitlab.haskell.org:ghc/ghc >>>> >>>> This is all that should be necessary; a quick `git pull origin master` >>>> should verify that everything is working as expected. >>>> >>>> >>>> # Continuous integration >>>> >>>> Continuous integration is now provided by GitLab's native continuous >>>> inte
Re: Welcome to GitLab!
Thanks ben! Great to know. CC the list in case anyone else was interested. _ara > On 27 Dec 2018, at 15:06, Ben Gamari wrote: > > Ara Adkins writes: > >> Along the lines of things needing to be adapted, are we moving the >> ghc-commits mailing list over to GL? >> > Yes, although I haven't quite worked out how best to do that yet. In the > meantime I have inverted the mirroring relationship between > git.haskell.org and gitlab.haskell.org such that the old commit > notification continue to fire. > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
The Trac Wiki and the GitLab Migration
Hey All, I’ve been doing a decent amount of thinking about the GitLab migration and realised that I’d not seen any discussion of what we plan to do with all the information in the Trac Wiki. If there has been some and I’ve missed it I apologise. In essence, I’m wondering what the current plan is! Will we leave it in place, or so we plan to move the content to a wiki on GitLab? Best. _ara ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: The Trac Wiki and the GitLab Migration
Brilliant. Thanks Ben and Brandon for the quick responses. Ben, if there’s any way I can help wit that migration, even to the point of manual cleanup, do let me know! _ara > On 28 Dec 2018, at 20:13, Ben Gamari wrote: > > Ara Adkins writes: > >> Hey All, >> >> I’ve been doing a decent amount of thinking about the GitLab migration >> and realised that I’d not seen any discussion of what we plan to do >> with all the information in the Trac Wiki. If there has been some and >> I’ve missed it I apologise. >> >> In essence, I’m wondering what the current plan is! Will we leave it >> in place, or so we plan to move the content to a wiki on GitLab? >> > The wiki content will also be moved to GitLab. However, the > content in the Wiki tends to use significantly richer markup which has > posed trouble for the markup conversion. The conversion will almost > certainly require a bit of manual cleanup; we are currently trying to > workout the right compromise between manual post-processing and fixing > the Trac parser. > > Cheers, > > - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
The GHC Proposals Process
Hey All, Now we have our own git instance in GitLab, are there any plans to move the proposals process from GitHub? _ara ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: The GHC Proposals Process
I certainly have no compelling reasons to do so! It was more a question than anything else, as I happen to agree that the reach of GitHub is beneficial in this case! _ara > On 4 Jan 2019, at 18:56, Ben Gamari wrote: > >> On January 4, 2019 12:56:58 PM EST, Ara Adkins wrote: >> Hey All, >> >> Now we have our own git instance in GitLab, are there any plans to move >> the >> proposals process from GitHub? >> >> _ara > > I haven't considered the possibility of moving the proposal process and I'm > not sure I see a compelling reason to do so. I would be happy to consider > arguments otherwise but it seems to me that the process is running reasonably > well on GitHub and benefits from the broad reach that GitHub provides. > > Cheers, > > - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration
Super excited for this! Thank you to everyone whose put in so much hard work to get it done! One question: what is happening with the trac tickets mailing list? I imagine it’ll be going away, but for those of us that use it to keep track of things is there a recommended alternative? Best, _ara > On 6 Mar 2019, at 01:21, Ben Gamari wrote: > > Hi everyone, > > Over the past few weeks we have been hard at work sorting out the > last batch of issues in GHC's Trac-to-GitLab import [1]. At this point I > believe we have sorted out the issues which are necessary to perform the > final migration: > > * We are missing only two tickets (#1436 and #2074 which will require a > bit of manual intervention to import due to extremely large > description lengths) > > * A variety of markup issues have been resolved > > * More metadata is now preserved via labels. We may choose to > reorganize or eliminate some of these labels in time but it's easier > to remove metadata after import than it is to reintroduce it. The > logic which maps Trac metadata to GitLab labels can be found here [2] > > * We now generate a Wiki table of contents [3] which is significantly > more readable than GitLab's default page list. This will be updated > by a cron job until underlying GitLab pages list becomes more > readable. > > * We now generate redirects for Trac ticket and Wiki links (although > this isn't visible in the staging instance) > > * Milestones are now properly closed when closed in Trac > > * Mapping between Trac and GitLab usernames is now a bit more robust > > As in previous test imports, we would appreciate it if you could have a > look over the import and let us know of any problems your encounter. > > If no serious issues are identified with the staging site we plan to > proceed with the migration this coming weekend. The current migration > plan is to perform the final import on gitlab.haskell.org on Saturday, 9 > March 2019. > > This will involve both gitlab.haskell.org and ghc.haskell.org being down > for likely the entirety of the day Saturday and likely some of Sunday > (EST time zone). Read-only access will be available to > gitlab.staging.haskell.org for ticket lookup while the import is > underway. > > After the import we will wait at least a week or so before we begin the > process of decommissioning Trac, which will be kept in read-only mode > for the duration. > > Do let me know if the 9 March timing is problematic. > > Cheers, > > - Ben > > > [1] https://gitlab.staging.haskell.org/ghc/ghc > [2] > https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 > [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index > ___ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration
Personally I would like to see it continued, but it may not be worth the work if I’m in a minority here. A potential stopgap would be to ‘watch’ the GHC project on our gitlab instance, but I can’t see any way to decide to get emails for notifications rather than having to check in at GitLab all the time. _ara > On 6 Mar 2019, at 11:21, Ben Gamari wrote: > > > >> On March 6, 2019 6:11:49 AM EST, Ara Adkins wrote: >> Super excited for this! Thank you to everyone whose put in so much hard >> work to get it done! >> >> One question: what is happening with the trac tickets mailing list? I >> imagine it’ll be going away, but for those of us that use it to keep >> track of things is there a recommended alternative? >> > The ghc-commits list will continue to work. > > The ghc-tickets list is a good question. I suspect that under gitlab there > will be less need for this list but we may still want to continue maintaining > it regardless for continuity's sake. Thoughts? > > Cheers, > > - Ben > > > >> Best, >> _ara >> >>> On 6 Mar 2019, at 01:21, Ben Gamari wrote: >>> >>> Hi everyone, >>> >>> Over the past few weeks we have been hard at work sorting out the >>> last batch of issues in GHC's Trac-to-GitLab import [1]. At this >> point I >>> believe we have sorted out the issues which are necessary to perform >> the >>> final migration: >>> >>> * We are missing only two tickets (#1436 and #2074 which will require >> a >>> bit of manual intervention to import due to extremely large >>> description lengths) >>> >>> * A variety of markup issues have been resolved >>> >>> * More metadata is now preserved via labels. We may choose to >>> reorganize or eliminate some of these labels in time but it's >> easier >>> to remove metadata after import than it is to reintroduce it. The >>> logic which maps Trac metadata to GitLab labels can be found here >> [2] >>> >>> * We now generate a Wiki table of contents [3] which is significantly >>> more readable than GitLab's default page list. This will be updated >>> by a cron job until underlying GitLab pages list becomes more >>> readable. >>> >>> * We now generate redirects for Trac ticket and Wiki links (although >>> this isn't visible in the staging instance) >>> >>> * Milestones are now properly closed when closed in Trac >>> >>> * Mapping between Trac and GitLab usernames is now a bit more robust >>> >>> As in previous test imports, we would appreciate it if you could have >> a >>> look over the import and let us know of any problems your encounter. >>> >>> If no serious issues are identified with the staging site we plan to >>> proceed with the migration this coming weekend. The current migration >>> plan is to perform the final import on gitlab.haskell.org on >> Saturday, 9 >>> March 2019. >>> >>> This will involve both gitlab.haskell.org and ghc.haskell.org being >> down >>> for likely the entirety of the day Saturday and likely some of Sunday >>> (EST time zone). Read-only access will be available to >>> gitlab.staging.haskell.org for ticket lookup while the import is >>> underway. >>> >>> After the import we will wait at least a week or so before we begin >> the >>> process of decommissioning Trac, which will be kept in read-only mode >>> for the duration. >>> >>> Do let me know if the 9 March timing is problematic. >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> [1] https://gitlab.staging.haskell.org/ghc/ghc >>> [2] >> https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 >>> [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index >>> ___ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration
That would be perfect if so. I couldn't find a way to do it when I looked earlier, but I may well have missed something! On Wed, 6 Mar 2019 at 12:33, Matthew Pickering wrote: > I think gitlab can be configured so notifications are sent for new issues > and comments on issues which should achieve the same thing as the mailing > list did? > > > > On Wed, Mar 6, 2019 at 12:00 PM Sylvain Henry wrote: > >> I use it to track tickets and I would also like to see it continued. >> >> Sylvain >> >> On 06/03/2019 12:33, Ara Adkins wrote: >> > Personally I would like to see it continued, but it may not be worth >> the work if I’m in a minority here. >> > >> > A potential stopgap would be to ‘watch’ the GHC project on our gitlab >> instance, but I can’t see any way to decide to get emails for notifications >> rather than having to check in at GitLab all the time. >> > >> > _ara >> > >> >> On 6 Mar 2019, at 11:21, Ben Gamari wrote: >> >> >> >> >> >> >> >>> On March 6, 2019 6:11:49 AM EST, Ara Adkins wrote: >> >>> Super excited for this! Thank you to everyone whose put in so much >> hard >> >>> work to get it done! >> >>> >> >>> One question: what is happening with the trac tickets mailing list? I >> >>> imagine it’ll be going away, but for those of us that use it to keep >> >>> track of things is there a recommended alternative? >> >>> >> >> The ghc-commits list will continue to work. >> >> >> >> The ghc-tickets list is a good question. I suspect that under gitlab >> there will be less need for this list but we may still want to continue >> maintaining it regardless for continuity's sake. Thoughts? >> >> >> >> Cheers, >> >> >> >> - Ben >> >> >> >> >> >> >> >>> Best, >> >>> _ara >> >>> >> >>>> On 6 Mar 2019, at 01:21, Ben Gamari wrote: >> >>>> >> >>>> Hi everyone, >> >>>> >> >>>> Over the past few weeks we have been hard at work sorting out the >> >>>> last batch of issues in GHC's Trac-to-GitLab import [1]. At this >> >>> point I >> >>>> believe we have sorted out the issues which are necessary to perform >> >>> the >> >>>> final migration: >> >>>> >> >>>> * We are missing only two tickets (#1436 and #2074 which will require >> >>> a >> >>>> bit of manual intervention to import due to extremely large >> >>>> description lengths) >> >>>> >> >>>> * A variety of markup issues have been resolved >> >>>> >> >>>> * More metadata is now preserved via labels. We may choose to >> >>>> reorganize or eliminate some of these labels in time but it's >> >>> easier >> >>>> to remove metadata after import than it is to reintroduce it. The >> >>>> logic which maps Trac metadata to GitLab labels can be found here >> >>> [2] >> >>>> * We now generate a Wiki table of contents [3] which is significantly >> >>>> more readable than GitLab's default page list. This will be updated >> >>>> by a cron job until underlying GitLab pages list becomes more >> >>>> readable. >> >>>> >> >>>> * We now generate redirects for Trac ticket and Wiki links (although >> >>>> this isn't visible in the staging instance) >> >>>> >> >>>> * Milestones are now properly closed when closed in Trac >> >>>> >> >>>> * Mapping between Trac and GitLab usernames is now a bit more robust >> >>>> >> >>>> As in previous test imports, we would appreciate it if you could have >> >>> a >> >>>> look over the import and let us know of any problems your encounter. >> >>>> >> >>>> If no serious issues are identified with the staging site we plan to >> >>>> proceed with the migration this coming weekend. The current migration >> >>>> plan is to perform the final import on gitlab.haskell.org on >> >>> Saturday, 9 >> >>>> March 2019. >> >>>> >> >>>> Th
Re: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration
I think that's a reliable replacement for the ghc-tickets mailing list if it works well. I'll have to see once the cut-over happens! On Wed, 6 Mar 2019 at 16:44, Ben Gamari wrote: > Ara Adkins writes: > > > That would be perfect if so. I couldn't find a way to do it when I looked > > earlier, but I may well have missed something! > > > If you navigate to the GHC project page [1] while logged in you should > find a little bell [2] button to the right of the "GHC" heading. If you > click on this and select "Custom" from the drop-down you can choose > precisely which notifications you want sent. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/ghc > [2] > https://docs.gitlab.com/ee/workflow/notifications.html#project-settings > ___ > 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: Trac to GitLab migration underway
Thanks for all the hard work to all involved! I’m very excited for everything to be in one place! _ara > On 10 Mar 2019, at 22:15, Shayne Fletcher via ghc-devs > wrote: > > > >> On Sun, Mar 10, 2019 at 5:38 PM Ben Gamari wrote: >> Ben Gamari writes: >> >> > Hello everyone, >> > >> > I have started the process of migrating GHC's Trac content to GitLab. >> > GitLab (gitlab.haskell.org) and Trac (ghc.haskell.org) will be down >> > until this process has finished. I will post updates as necessary. >> > >> Hi everyone, >> >> I'm happy to announce that the ticket and issue import processes are now >> complete and gitlab.haskell.org is back online. > [...] > > Thanks for your hard work! > >> Cheers, >> >> - Ben >> >> >> >> [1] https://gitlab.haskell.org/bgamari/gitlab-migration/issues >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > This message, and any attachments, is for the intended recipient(s) only, may > contain information that is privileged, confidential and/or proprietary and > subject to important terms and conditions available at > http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended > recipient, please delete this message. > ___ > 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
Marge Bot Permissions on Trac
Hey all, though mostly hey Ben, Just figured I should let you know that marge still seems to be making changes to trac tickets as of about four hours ago when sending this email. Best, _ara ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Gitlab Email Broken (again)
The same thing seems to have happened to me too. _ara > On 13 Mar 2019, at 07:39, Matthew Pickering > wrote: > > HI Ben, > > I am not receiving emails from gitlab again. Is there a way we can > make email more robust? > > Matt > ___ > 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
Merge Request Submission Confusion
Hey all, I'm trying to submit a minor MR as described on the wiki [0]. I can't seem to find the mentioned 'New Merge Request' button, however. Do I need a specific set of permissions to open MRs? Any pointers would be appreciated. Best, _ara [0] https://gitlab.haskell.org/ghc/ghc/wikis/home#opening-a-merge-request ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Merge Request Submission Confusion
I don't, which is the curious thing. There's just a gap above the filter dropdown where it should be. On Mon, 8 Apr 2019 at 13:56, Ben Gamari wrote: > > Ara Adkins writes: > > > Hey all, > > > > I'm trying to submit a minor MR as described on the wiki [0]. I can't > > seem to find the mentioned 'New Merge Request' button, however. Do I > > need a specific set of permissions to open MRs? > > > > Any pointers would be appreciated. > > > Do you see a "New merge request" button in the top right (below the > navigation bar) of this page [1]? > > You can also navigate to any page under the ghc/ghc project and there > should be a "New merge request" entry under the "+" menu in the navbar. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/ghc/merge_requests ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Merge Request Submission Confusion
Thanks so much Ben! That seems to have done the trick. Unfortunately I seem to have hit another hurdle, as my fork doesn't seem to be in the list of potential sources at all [0]. Similarly if I try and start the MR from within my fork, the only target is my fork. It's like it's lost its parent relationship to the main GHC repo. Any idea why that would be? I did fork quite a while back, so maybe something got borked in one of the various GitLab upgrade snafus. I tried to delete the fork and fork again, figuring that I could just push my changes from my local, but the deletion has failed with "This project was scheduled for deletion, but failed with the following message: Permission denied @ rb_sysopen - /var/lib/acme/gitlab.haskell.org/registry-auth.key " Remarkably odd. Sorry to load all these things onto your plate! Best, _ara [0] https://gitlab.haskell.org/iamrecursion/ghc On Mon, 8 Apr 2019 at 19:22, Ben Gamari wrote: > > Ara Adkins writes: > > > I don't, which is the curious thing. There's just a gap above the > > filter dropdown where it should be. > > > Hmm, it's possible this is related to the fact that you had only > reporter privileges. I just gave you the developer role; have things > changed at all? > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Merge Request Submission Confusion
Perhaps the current 'my fork is not available' mess is actually the root cause, then? On Mon, 8 Apr 2019 at 21:56, Artem Pelenitsyn wrote: > > On Mon, 8 Apr 2019 at 14:22 Ben Gamari wrote: >> >> Ara Adkins writes: >> >> > I don't, which is the curious thing. There's just a gap above the >> > filter dropdown where it should be. >> > >> Hmm, it's possible this is related to the fact that you had only >> reporter privileges. > > > Just a datapoint here: I have only Reporter rights, and I do see "New Merge > Request" button on the "Merge Requests" page of the ghc/ghc project. And I'm > pretty sure I had it back when I didn't have any (non-trivial) permissions. > > -- > Best, Artem > > >> >> I just gave you the developer role; have things >> changed at all? >> >> Cheers, >> >> - Ben >> >> ___ >> 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: Marge bot UX improvement suggestion
Yeah I just got a flood of a few hundred emails from ‘Moe Bot’. _ara > On 26 Apr 2019, at 10:41, Phyx wrote: > > Speaking of bots.. What's a Moe bot? Haha. > > Sent from my Mobile > >> On Thu, Apr 25, 2019, 16:06 Ben Gamari wrote: >> Ömer Sinan Ağacan writes: >> >> > I think it'd be useful if Marge listed commits that it's trying to merge >> > in the >> > description of the MR so that we could get a list of commits in the emails. >> > Currently the emails just say "Marge Bot Barch MR - DO NOT TOUCH" with an >> > empty >> > body. >> > >> I'm generally reluctant to invest any more effort into Marge. She's in >> general barely holding together and hopefully within a month we'll be >> able to move to GitLab's native merge train solution. >> >> Cheers, >> >> - Ben >> >> ___ >> 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Moe Bot
Hey David, This is going to be a great boon! Thanks so much for your hard work on this! _ara > On 26 Apr 2019, at 11:16, David Eichmann wrote: > > Hello All, > > I've been working on Moe Bot recently who will quote commits that mention > issues. When a commit is pushed to master, Moe will create a new comment on > the referenced issue quoting the full commit message. This is for your > convenience so you can avoid having to navigate off the page to see the full > commit message. > > Unfortunately this has triggered a large number of notification emails as Moe > works to quote existing commits. You can safely ignore emails from Moe. I've > disabled him for now. Sorry for the disturbance this morning. > > David Eichmann > > -- > David Eichmann, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com > > Registered in England & Wales, OC335890 > 118 Wymering Mansions, Wymering Road, London W9 2NF, England > ___ > 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
