Moving head.hackage upstream

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Moving head.hackage upstream

Ben Gamari-3
Hi Herbert,

Last week I did some work to clean up and document GHC's head.hackage
infrastructure. At this point we have a full CI pipeline, including
automatic deployment of a Hackage repository.

I asked on #ghc and there was quite some appetite to use
gitlab.haskell.org:ghc/head.hackage as the head.hackage upstream
repository to eliminate confusion and enjoy the benefits of having merge
requests checked via CI. Moreover, this would significantly simplify the
process of testing GHC against head.hackage as it would eliminate the need
to pull from a separate upstream repository.

Would you be okay with moving head.hackage's upstream?

Thanks again for everything you have done in the head.hackage area.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving head.hackage upstream

Ben Gamari-3
Ben Gamari <[hidden email]> writes:

> Hi Herbert,
>
> Last week I did some work to clean up and document GHC's head.hackage
> infrastructure. At this point we have a full CI pipeline, including
> automatic deployment of a Hackage repository.
>
> I asked on #ghc and there was quite some appetite to use
> gitlab.haskell.org:ghc/head.hackage as the head.hackage upstream
> repository to eliminate confusion and enjoy the benefits of having merge
> requests checked via CI. Moreover, this would significantly simplify the
> process of testing GHC against head.hackage as it would eliminate the need
> to pull from a separate upstream repository.
>
> Would you be okay with moving head.hackage's upstream?
>
> Thanks again for everything you have done in the head.hackage area.
>
I probably should mention that I have documented our infrastructure in
two blog posts which I hope to publish this week or next [1,2].

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/homepage/merge_requests/16
[2] https://gitlab.haskell.org/ghc/homepage/merge_requests/29

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving head.hackage upstream

Ryan Scott
In reply to this post by Ben Gamari-3
Count me among the people who are eagerly awaiting this move. If I understood Ben correctly when discussing this idea with him on #ghc, then one of the benefits of having head.hackage on GitLab would be that the head.hackage index would automatically regenerate any time a commit lands. This would make things far more streamlined than the status quo, where the index has to be regenerated by hand.

If head.hackage is migrated over to GitLab, would that change how people are expected to use it? That is, would it still be as simple as copying the repository stanza from [1] into one's cabal.project file? Or would that change with a move to GitLab?

Ryan S.
-----

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving head.hackage upstream

Ben Gamari-3
Ryan Scott <[hidden email]> writes:

> Count me among the people who are eagerly awaiting this move. If I
> understood Ben correctly when discussing this idea with him on #ghc, then
> one of the benefits of having head.hackage on GitLab would be that the
> head.hackage index would automatically regenerate any time a commit lands.
> This would make things far more streamlined than the status quo, where the
> index has to be regenerated by hand.
>
> If head.hackage is migrated over to GitLab, would that change how people
> are expected to use it? That is, would it still be as simple as copying the
> repository stanza from [1] into one's cabal.project file? Or would that
> change with a move to GitLab?
>
There is the question of what would happen to
http://head.hackage.haskell.org/. The CI-generated repository is
currently deployed via GitLab Pages to
http://ghc.gitlab.haskell.org/head.hackage/; the user's experience
otherwise does not change. It would be easy to redirect
head.hackage.haskell.org there is that is okay with hvr.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving head.hackage upstream

Ben Gamari-3
In reply to this post by Ben Gamari-3
Ben Gamari <[hidden email]> writes:

> Hi Herbert,
>
> Last week I did some work to clean up and document GHC's head.hackage
> infrastructure. At this point we have a full CI pipeline, including
> automatic deployment of a Hackage repository.
>
> I asked on #ghc and there was quite some appetite to use
> gitlab.haskell.org:ghc/head.hackage as the head.hackage upstream
> repository to eliminate confusion and enjoy the benefits of having merge
> requests checked via CI. Moreover, this would significantly simplify the
> process of testing GHC against head.hackage as it would eliminate the need
> to pull from a separate upstream repository.
>
> Would you be okay with moving head.hackage's upstream?
>
Just a gentle ping on this, Herbert.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving head.hackage upstream

Ben Gamari-3
In reply to this post by Ben Gamari-3
Ben Gamari <[hidden email]> writes:

> Hi Herbert,
>
> Last week I did some work to clean up and document GHC's head.hackage
> infrastructure. At this point we have a full CI pipeline, including
> automatic deployment of a Hackage repository.
>
> I asked on #ghc and there was quite some appetite to use
> gitlab.haskell.org:ghc/head.hackage as the head.hackage upstream
> repository to eliminate confusion and enjoy the benefits of having merge
> requests checked via CI. Moreover, this would significantly simplify the
> process of testing GHC against head.hackage as it would eliminate the need
> to pull from a separate upstream repository.
>
> Would you be okay with moving head.hackage's upstream?
>
> Thanks again for everything you have done in the head.hackage area.
>
Herbert and I discussed this via IRC over the weekend and he said he
would be fine with moving head.hackage's upstream to GitLab.

Herbert, can you change the description of your GitHub repository to
reflect this?

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment