Can't push to haddock

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

Can't push to haddock

GHC - devs mailing list

I’m trying to push a patch that needs a supporting change to haddock.

I’ve pushed the haddock change to the ghc-head branch of ssh://[hidden email]/haskell/haddock.git, which is (according to ‘packages’) the relevant haddock upstream repo.

But when I try to push the GHC patch, I get this message

bash$ git push

Counting objects: 45, done.

Delta compression using up to 32 threads.

Compressing objects: 100% (45/45), done.

Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.

Total 45 (delta 43), reused 0 (delta 0)

remote: performing commit message validations...       

remote: Commit message validation passed!       

remote: performing submodule-ref update validations...       

remote: Submodule update(s) detected in fa29df02a1b0b926afb2525a258172dcbf0ea460:       

remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65       

remote: *FAIL* commit not found in submodule repo ('../haddock.git')       

remote:        or not reachable from persistent branches       

remote: hooklet hooks/update.secondary.d/check-submodule-refs failed       

remote: hooks/update.secondary died        

remote: error: hook declined to update refs/heads/master       

To ssh://[hidden email]/ghc.git

! [remote rejected] HEAD -> master (hook declined)

error: failed to push some refs to 'ssh://[hidden email]/ghc.git'

simonpj@cam-05-unx:~/code/HEAD$

 

What’s up?  I  have pushed the haddock commit!

THanks

Simon

 


_______________________________________________
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: Can't push to haddock

GHC - devs mailing list

But when I try to push the GHC patch, I get this message

Ah… it worked after a while. Maybe a mirroring thing?

But in pushing to GHC I saw:

git push

Counting objects: 45, done.

Delta compression using up to 32 threads.

Compressing objects: 100% (45/45), done.

Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.

Total 45 (delta 43), reused 0 (delta 0)

remote: performing commit message validations...       

remote: Commit message validation passed!       

remote: performing submodule-ref update validations...       

remote: Submodule update(s) detected in fa29df02a1b0b926afb2525a258172dcbf0ea460:       

remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65       

remote:  utils/hsc2hs => 9483ad10064fbbb97ab525280623826b1ef63959       

remote:  OK       

remote: performing whitespace validations...       

remote: whitespace validation passed!       

remote: mirroring ssh://[hidden email]/ghc to ssh://[hidden email]/ghc/ghc ...       

remote: To ssh://[hidden email]/ghc/ghc       

remote:    5f332e1..fa29df0  master -> master       

remote: running notifier       

To ssh://[hidden email]/ghc.git

   5f332e1..fa29df0  HEAD -> master

simonpj@cam-05-unx:~/code/HEAD$

I did not intend to monkey around with hsc2hs. I can’t think how that happened, or whether it matter.

With many apologies, would a wiser person that me like to see if I’ve accidentally messed up hsc2hs. 

Thanks

Simon

 

From: ghc-devs [mailto:[hidden email]] On Behalf Of Simon Peyton Jones via ghc-devs
Sent: 07 December 2017 17:32
To: [hidden email]
Subject: Can't push to haddock

 

I’m trying to push a patch that needs a supporting change to haddock.

I’ve pushed the haddock change to the ghc-head branch of ssh://[hidden email]/haskell/haddock.git, which is (according to ‘packages’) the relevant haddock upstream repo.

But when I try to push the GHC patch, I get this message

bash$ git push

Counting objects: 45, done.

Delta compression using up to 32 threads.

Compressing objects: 100% (45/45), done.

Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.

Total 45 (delta 43), reused 0 (delta 0)

remote: performing commit message validations...       

remote: Commit message validation passed!       

remote: performing submodule-ref update validations...       

remote: Submodule update(s) detected in fa29df02a1b0b926afb2525a258172dcbf0ea460:       

remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65       

remote: *FAIL* commit not found in submodule repo ('../haddock.git')       

remote:        or not reachable from persistent branches       

remote: hooklet hooks/update.secondary.d/check-submodule-refs failed       

remote: hooks/update.secondary died        

remote: error: hook declined to update refs/heads/master       

To ssh://[hidden email]/ghc.git

! [remote rejected] HEAD -> master (hook declined)

error: failed to push some refs to 'ssh://[hidden email]/ghc.git'

simonpj@cam-05-unx:~/code/HEAD$

 

What’s up?  I  have pushed the haddock commit!

THanks

Simon

 


_______________________________________________
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: Can't push to haddock

GHC - devs mailing list
|  Yes, the mirroring has a little bit of latency (assuming the mirroring
|  trigger event notification from github to git.haskell.org didn't get
|  lost). How much time did you wait between pushing to github and
|  ghc.git?

I didn't allow any time -- I didn't know that time was needed. Perhaps we should add a note to
https://ghc.haskell.org/trac/ghc/wiki/Repositories
to explain?  Under "Updating sub-repos" perhaps.

I wonder if it'd be worth us articulating the reason why some submodules live in github, but some live in git.haskell.org -- with only mirroring github.  I'm sure there's a rationale but I don't get it yet.

Simon


|  -----Original Message-----
|  From: Herbert Valerio Riedel [mailto:[hidden email]]
|  Sent: 07 December 2017 17:57
|  To: Simon Peyton Jones <[hidden email]>
|  Subject: Re: Can't push to haddock
|  
|  Hi Simon,
|  
|  Yes, the mirroring has a little bit of latency (assuming the mirroring
|  trigger event notification from github to git.haskell.org didn't get
|  lost). How much time did you wait between pushing to github and
|  ghc.git?
|  
|  On Thu, Dec 7, 2017 at 6:53 PM, Simon Peyton Jones via ghc-devs <ghc-
|  [hidden email]> wrote:
|  > But when I try to push the GHC patch, I get this message
|  >
|  > Ah… it worked after a while. Maybe a mirroring thing?
|  >
|  > But in pushing to GHC I saw:
|  >
|  > git push
|  >
|  > Counting objects: 45, done.
|  >
|  > Delta compression using up to 32 threads.
|  >
|  > Compressing objects: 100% (45/45), done.
|  >
|  > Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.
|  >
|  > Total 45 (delta 43), reused 0 (delta 0)
|  >
|  > remote: performing commit message validations...
|  >
|  > remote: Commit message validation passed!
|  >
|  > remote: performing submodule-ref update validations...
|  >
|  > remote: Submodule update(s) detected in
|  > fa29df02a1b0b926afb2525a258172dcbf0ea460:
|  >
|  > remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65
|  >
|  > remote:  utils/hsc2hs => 9483ad10064fbbb97ab525280623826b1ef63959
|  >
|  > remote:  OK
|  >
|  > remote: performing whitespace validations...
|  >
|  > remote: whitespace validation passed!
|  >
|  > remote: mirroring ssh://[hidden email]/ghc to
|  > ssh://[hidden email]/ghc/ghc ...
|  >
|  > remote: To ssh://[hidden email]/ghc/ghc
|  >
|  > remote:    5f332e1..fa29df0  master -> master
|  >
|  > remote: running notifier
|  >
|  > To ssh://[hidden email]/ghc.git
|  >
|  >    5f332e1..fa29df0  HEAD -> master
|  >
|  > simonpj@cam-05-unx:~/code/HEAD$
|  >
|  > I did not intend to monkey around with hsc2hs. I can’t think how
|  that
|  > happened, or whether it matter.
|  >
|  > With many apologies, would a wiser person that me like to see if
|  I’ve
|  > accidentally messed up hsc2hs.
|  >
|  > Thanks
|  >
|  > Simon
|  >
|  >
|  >
|  > From: ghc-devs [mailto:[hidden email]] On Behalf Of
|  > Simon Peyton Jones via ghc-devs
|  > Sent: 07 December 2017 17:32
|  > To: [hidden email]
|  > Subject: Can't push to haddock
|  >
|  >
|  >
|  > I’m trying to push a patch that needs a supporting change to
|  haddock.
|  >
|  > I’ve pushed the haddock change to the ghc-head branch of
|  > ssh://[hidden email]/haskell/haddock.git, which is (according to
|  > ‘packages’) the relevant haddock upstream repo.
|  >
|  > But when I try to push the GHC patch, I get this message
|  >
|  > bash$ git push
|  >
|  > Counting objects: 45, done.
|  >
|  > Delta compression using up to 32 threads.
|  >
|  > Compressing objects: 100% (45/45), done.
|  >
|  > Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.
|  >
|  > Total 45 (delta 43), reused 0 (delta 0)
|  >
|  > remote: performing commit message validations...
|  >
|  > remote: Commit message validation passed!
|  >
|  > remote: performing submodule-ref update validations...
|  >
|  > remote: Submodule update(s) detected in
|  > fa29df02a1b0b926afb2525a258172dcbf0ea460:
|  >
|  > remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65
|  >
|  > remote: *FAIL* commit not found in submodule repo ('../haddock.git')
|  >
|  > remote:        or not reachable from persistent branches
|  >
|  > remote: hooklet hooks/update.secondary.d/check-submodule-refs failed
|  >
|  > remote: hooks/update.secondary died
|  >
|  > remote: error: hook declined to update refs/heads/master
|  >
|  > To ssh://[hidden email]/ghc.git
|  >
|  > ! [remote rejected] HEAD -> master (hook declined)
|  >
|  > error: failed to push some refs to
|  'ssh://[hidden email]/ghc.git'
|  >
|  > simonpj@cam-05-unx:~/code/HEAD$
|  >
|  >
|  >
|  > What’s up?  I  have pushed the haddock commit!
|  >
|  > THanks
|  >
|  > Simon
|  >
|  >
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > [hidden email]
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=02%7C01%7Csimonpj%40microsoft.com%7C684b5c6cdac34213317708d5
|  3d9be387%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364826622509770
|  90&sdata=kMhG2iTALLRxhwyDw%2BzTN8VvMMn%2FqfvnSn9cPm0AK4Q%3D&reserved=0
|  >
_______________________________________________
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: Can't push to haddock

lonetiger


On Fri, Dec 8, 2017, 10:13 Simon Peyton Jones via ghc-devs <[hidden email]> wrote:
|  Yes, the mirroring has a little bit of latency (assuming the mirroring
|  trigger event notification from github to git.haskell.org didn't get
|  lost). How much time did you wait between pushing to github and
|  ghc.git?

I didn't allow any time -- I didn't know that time was needed. Perhaps we should add a note to
https://ghc.haskell.org/trac/ghc/wiki/Repositories
to explain?  Under "Updating sub-repos" perhaps.

I wonder if it'd be worth us articulating the reason why some submodules live in github, but some live in git.haskell.org -- with only mirroring github.  I'm sure there's a rationale but I don't get it yet.

Simon


The general scheme seems to be anything under the haskell organization is primarily on github and mirrored to haskell.org. (this of course includes Hadrian which is in another org). The things under the ghc org are haskell.org focused and mirrored to github. 



|  -----Original Message-----
|  From: Herbert Valerio Riedel [mailto:[hidden email]]
|  Sent: 07 December 2017 17:57
|  To: Simon Peyton Jones <[hidden email]>
|  Subject: Re: Can't push to haddock
|
|  Hi Simon,
|
|  Yes, the mirroring has a little bit of latency (assuming the mirroring
|  trigger event notification from github to git.haskell.org didn't get
|  lost). How much time did you wait between pushing to github and
|  ghc.git?
|
|  On Thu, Dec 7, 2017 at 6:53 PM, Simon Peyton Jones via ghc-devs <ghc-
[hidden email]> wrote:
|  > But when I try to push the GHC patch, I get this message
|  >
|  > Ah… it worked after a while. Maybe a mirroring thing?
|  >
|  > But in pushing to GHC I saw:
|  >
|  > git push
|  >
|  > Counting objects: 45, done.
|  >
|  > Delta compression using up to 32 threads.
|  >
|  > Compressing objects: 100% (45/45), done.
|  >
|  > Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.
|  >
|  > Total 45 (delta 43), reused 0 (delta 0)
|  >
|  > remote: performing commit message validations...
|  >
|  > remote: Commit message validation passed!
|  >
|  > remote: performing submodule-ref update validations...
|  >
|  > remote: Submodule update(s) detected in
|  > fa29df02a1b0b926afb2525a258172dcbf0ea460:
|  >
|  > remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65
|  >
|  > remote:  utils/hsc2hs => 9483ad10064fbbb97ab525280623826b1ef63959
|  >
|  > remote:  OK
|  >
|  > remote: performing whitespace validations...
|  >
|  > remote: whitespace validation passed!
|  >
|  > remote: mirroring ssh://git@.../ghc to
|  > ssh://git@.../ghc/ghc ...
|  >
|  > remote: To ssh://git@.../ghc/ghc
|  >
|  > remote:    5f332e1..fa29df0  master -> master
|  >
|  > remote: running notifier
|  >
|  > To ssh://git@.../ghc.git
|  >
|  >    5f332e1..fa29df0  HEAD -> master
|  >
|  > simonpj@cam-05-unx:~/code/HEAD$
|  >
|  > I did not intend to monkey around with hsc2hs. I can’t think how
|  that
|  > happened, or whether it matter.
|  >
|  > With many apologies, would a wiser person that me like to see if
|  I’ve
|  > accidentally messed up hsc2hs.
|  >
|  > Thanks
|  >
|  > Simon
|  >
|  >
|  >
|  > From: ghc-devs [mailto:[hidden email]] On Behalf Of
|  > Simon Peyton Jones via ghc-devs
|  > Sent: 07 December 2017 17:32
|  > To: [hidden email]
|  > Subject: Can't push to haddock
|  >
|  >
|  >
|  > I’m trying to push a patch that needs a supporting change to
|  haddock.
|  >
|  > I’ve pushed the haddock change to the ghc-head branch of
|  > ssh://git@.../haskell/haddock.git, which is (according to
|  > ‘packages’) the relevant haddock upstream repo.
|  >
|  > But when I try to push the GHC patch, I get this message
|  >
|  > bash$ git push
|  >
|  > Counting objects: 45, done.
|  >
|  > Delta compression using up to 32 threads.
|  >
|  > Compressing objects: 100% (45/45), done.
|  >
|  > Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.
|  >
|  > Total 45 (delta 43), reused 0 (delta 0)
|  >
|  > remote: performing commit message validations...
|  >
|  > remote: Commit message validation passed!
|  >
|  > remote: performing submodule-ref update validations...
|  >
|  > remote: Submodule update(s) detected in
|  > fa29df02a1b0b926afb2525a258172dcbf0ea460:
|  >
|  > remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65
|  >
|  > remote: *FAIL* commit not found in submodule repo ('../haddock.git')
|  >
|  > remote:        or not reachable from persistent branches
|  >
|  > remote: hooklet hooks/update.secondary.d/check-submodule-refs failed
|  >
|  > remote: hooks/update.secondary died
|  >
|  > remote: error: hook declined to update refs/heads/master
|  >
|  > To ssh://git@.../ghc.git
|  >
|  > ! [remote rejected] HEAD -> master (hook declined)
|  >
|  > error: failed to push some refs to
|  'ssh://git@.../ghc.git'
|  >
|  > simonpj@cam-05-unx:~/code/HEAD$
|  >
|  >
|  >
|  > What’s up?  I  have pushed the haddock commit!
|  >
|  > THanks
|  >
|  > Simon
|  >
|  >
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > [hidden email]
|  >
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=02%7C01%7Csimonpj%40microsoft.com%7C684b5c6cdac34213317708d5
|  3d9be387%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364826622509770
|  90&sdata=kMhG2iTALLRxhwyDw%2BzTN8VvMMn%2FqfvnSn9cPm0AK4Q%3D&reserved=0
|  >
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
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: Can't push to haddock

GHC - devs mailing list

The general scheme seems to be anything under the haskell organization is primarily on github and mirrored to haskell.org. (this of course includes Hadrian which is in another org). The things under the ghc org are haskell.org focused and mirrored to github. 

My question is: why mirror?  At the moment, I think

  • we always pull from git.haskell.org
  • but for other-org packages we push to github
  • …and mirror on git.haskell.org.

 

But why don’t we just pull from github rather than mirroring on git.haskell.org?

 

Simon

 

 

From: Phyx [mailto:[hidden email]]
Sent: 16 December 2017 15:26
To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]
Subject: Re: Can't push to haddock

 

 

On Fri, Dec 8, 2017, 10:13 Simon Peyton Jones via ghc-devs <[hidden email]> wrote:

|  Yes, the mirroring has a little bit of latency (assuming the mirroring
|  trigger event notification from github to git.haskell.org didn't get
|  lost). How much time did you wait between pushing to github and
|  ghc.git?

I didn't allow any time -- I didn't know that time was needed. Perhaps we should add a note to
https://ghc.haskell.org/trac/ghc/wiki/Repositories
to explain?  Under "Updating sub-repos" perhaps.

I wonder if it'd be worth us articulating the reason why some submodules live in github, but some live in git.haskell.org -- with only mirroring github.  I'm sure there's a rationale but I don't get it yet.

Simon

 

 

The general scheme seems to be anything under the haskell organization is primarily on github and mirrored to haskell.org. (this of course includes Hadrian which is in another org). The things under the ghc org are haskell.org focused and mirrored to github. 

 



|  -----Original Message-----
|  From: Herbert Valerio Riedel [mailto:[hidden email]]
|  Sent: 07 December 2017 17:57
|  To: Simon Peyton Jones <[hidden email]>
|  Subject: Re: Can't push to haddock
|
|  Hi Simon,
|
|  Yes, the mirroring has a little bit of latency (assuming the mirroring
|  trigger event notification from github to git.haskell.org didn't get
|  lost). How much time did you wait between pushing to github and
|  ghc.git?
|
|  On Thu, Dec 7, 2017 at 6:53 PM, Simon Peyton Jones via ghc-devs <ghc-
[hidden email]> wrote:
|  > But when I try to push the GHC patch, I get this message
|  >
|  > Ah… it worked after a while. Maybe a mirroring thing?
|  >
|  > But in pushing to GHC I saw:
|  >
|  > git push
|  >
|  > Counting objects: 45, done.
|  >
|  > Delta compression using up to 32 threads.
|  >
|  > Compressing objects: 100% (45/45), done.
|  >
|  > Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.
|  >
|  > Total 45 (delta 43), reused 0 (delta 0)
|  >
|  > remote: performing commit message validations...
|  >
|  > remote: Commit message validation passed!
|  >
|  > remote: performing submodule-ref update validations...
|  >
|  > remote: Submodule update(s) detected in
|  > fa29df02a1b0b926afb2525a258172dcbf0ea460:
|  >
|  > remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65
|  >
|  > remote:  utils/hsc2hs => 9483ad10064fbbb97ab525280623826b1ef63959
|  >
|  > remote:  OK
|  >
|  > remote: performing whitespace validations...
|  >
|  > remote: whitespace validation passed!
|  >
|  > remote: mirroring ssh://git@.../ghc to
|  > ssh://git@.../ghc/ghc ...
|  >
|  > remote: To ssh://git@.../ghc/ghc
|  >
|  > remote:    5f332e1..fa29df0  master -> master
|  >
|  > remote: running notifier
|  >
|  > To ssh://git@.../ghc.git
|  >
|  >    5f332e1..fa29df0  HEAD -> master
|  >
|  > simonpj@cam-05-unx:~/code/HEAD$
|  >
|  > I did not intend to monkey around with hsc2hs. I can’t think how
|  that
|  > happened, or whether it matter.
|  >
|  > With many apologies, would a wiser person that me like to see if
|  I’ve
|  > accidentally messed up hsc2hs.
|  >
|  > Thanks
|  >
|  > Simon
|  >
|  >
|  >
|  > From: ghc-devs [mailto:[hidden email]] On Behalf Of
|  > Simon Peyton Jones via ghc-devs
|  > Sent: 07 December 2017 17:32
|  > To: [hidden email]
|  > Subject: Can't push to haddock
|  >
|  >
|  >
|  > I’m trying to push a patch that needs a supporting change to
|  haddock.
|  >
|  > I’ve pushed the haddock change to the ghc-head branch of
|  > ssh://git@.../haskell/haddock.git, which is (according to
|  > ‘packages’) the relevant haddock upstream repo.
|  >
|  > But when I try to push the GHC patch, I get this message
|  >
|  > bash$ git push
|  >
|  > Counting objects: 45, done.
|  >
|  > Delta compression using up to 32 threads.
|  >
|  > Compressing objects: 100% (45/45), done.
|  >
|  > Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.
|  >
|  > Total 45 (delta 43), reused 0 (delta 0)
|  >
|  > remote: performing commit message validations...
|  >
|  > remote: Commit message validation passed!
|  >
|  > remote: performing submodule-ref update validations...
|  >
|  > remote: Submodule update(s) detected in
|  > fa29df02a1b0b926afb2525a258172dcbf0ea460:
|  >
|  > remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65
|  >
|  > remote: *FAIL* commit not found in submodule repo ('../haddock.git')
|  >
|  > remote:        or not reachable from persistent branches
|  >
|  > remote: hooklet hooks/update.secondary.d/check-submodule-refs failed
|  >
|  > remote: hooks/update.secondary died
|  >
|  > remote: error: hook declined to update refs/heads/master
|  >
|  > To ssh://git@.../ghc.git
|  >
|  > ! [remote rejected] HEAD -> master (hook declined)
|  >
|  > error: failed to push some refs to
|  'ssh://git@.../ghc.git'
|  >
|  > simonpj@cam-05-unx:~/code/HEAD$
|  >
|  >
|  >
|  > What’s up?  I  have pushed the haddock commit!
|  >
|  > THanks
|  >
|  > Simon
|  >
|  >
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > [hidden email]
|  >
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=02%7C01%7Csimonpj%40microsoft.com%7C684b5c6cdac34213317708d5
|  3d9be387%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364826622509770
|  90&sdata=kMhG2iTALLRxhwyDw%2BzTN8VvMMn%2FqfvnSn9cPm0AK4Q%3D&reserved=0
|  >
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
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: Can't push to haddock

GHC - devs mailing list
|  It's for technical reasons, and the strongest one being: GitHub doesn't
|  allow us to establish strong invariants regarding submodule gitlink
|  referential integrity for submodules (which I implemented a couple years ago
|  for git.haskell.org).

Interesting.  It'd be good to document what the technical reasons are.  For example I don’t know what the strong invariants are.

A good place to describe them might be the Repositories pages
https://ghc.haskell.org/trac/ghc/wiki/Repositories

Many thanks

Simon

|  -----Original Message-----
|  From: Herbert Valerio Riedel [mailto:[hidden email]]
|  Sent: 18 December 2017 11:13
|  To: Simon Peyton Jones <[hidden email]>
|  Subject: Re: Can't push to haddock
|  
|  On Mon, Dec 18, 2017 at 10:01 AM, Simon Peyton Jones via ghc-devs <ghc-
|  [hidden email]> wrote:
|  > But why don’t we just pull from github rather than mirroring on
|  > git.haskell.org?
|  
|  It's for technical reasons, and the strongest one being: GitHub doesn't
|  allow us to establish strong invariants regarding submodule gitlink
|  referential integrity for submodules (which I implemented a couple years ago
|  for git.haskell.org).
_______________________________________________
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: Can't push to haddock

Sven Panne-2
2017-12-18 17:01 GMT+01:00 Simon Peyton Jones via ghc-devs <[hidden email]>:
|  It's for technical reasons, and the strongest one being: GitHub doesn't
|  allow us to establish strong invariants regarding submodule gitlink
|  referential integrity for submodules (which I implemented a couple years ago
|  for git.haskell.org).

Interesting.  It'd be good to document what the technical reasons are.  For example I don’t know what the strong invariants are. [...]

Me neither. :-] Looking at the repositories Wiki page, it seems to be related to the fact that GitHub doesn't offer git hooks, which are used to check the invariants. This leads to another question: Is it *really* necessary to have the invariant checks implemented as a git hook? If you use any kind of continuous integration, which GHC obviously does, one can move the checks to e.g. CircleCI (or whatever CI is used). This is a tradeoff: Doing it that way, you catch incorrect commits a little bit later, but it makes the overall arcane repository magic quite a bit simpler, probably removing the need for mirroring. This seems to be a good tradeoff, but of course I might be missing some details here.

_______________________________________________
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: Can't push to haddock

Herbert Valerio Riedel-3
Hi,

On 2017-12-19 at 08:31:06 +0100, Sven Panne wrote:

> This is a tradeoff: Doing it that way, you catch incorrect commits a
> little bit later, but it makes the overall arcane repository magic
> quite a bit simpler, probably removing the need for mirroring.

We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover; the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. As a Haskell programmer, I rather err on the side of
correctness for mission critical things, and shifting checks we can (and
already) do statically to CI feels to me like embracing
`-fdefer-type-errors`... :-)

Cheers,
  HVR
_______________________________________________
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: Can't push to haddock

Sven Panne-2
2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <[hidden email]>:
We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

I think this is a question of perspective: Having the master repository on GitHub doesn't mean you are in immediate danger or lose your "family jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that something goes wrong with GitHub, there is far more manpower behind it to fix that than for any self-hosted repository. And you can of course have some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco area... ;-)

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.
 
Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover;

This is by no means different than saying: "I want to run 'validate' in the commit hook, otherwise it's a big mess." We don't do this for obvious reasons, and what is the "big mess" if there is some incorrect submodule reference for a short time span? How is that different from somebody introducing e.g. a subtle compiler bug in a commit?
 
the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. [...]

Because the whole repository structure is overly complicated and simply hosting everything on GitHub would simplify things. Again: I'm well aware that there are tradeoffs involved, but I would really appreciate simplifications. I have the impression that the entry barrier to GHC development has become larger and larger over the years, partly because of very non-standard tooling, partly because of the increasingly arcane repository organization. There are reasons that other projects like Rust attract far more developers... :-/
</GrumpyMode>


_______________________________________________
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: Can't push to haddock

GHC - devs mailing list

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.

Speaking for myself, I have no hostility towards GitHub, and there is no GHC-HQ bias against it that I know of.  If it serves the purpose better, we should use it.   Indeed that’s why I asked my original question.  I agree with your point that data may actually be safer in GitHub than in our own repo.   (And there is nothing to stop a belt-and-braces mirror backup system.)

 

The issue is: does GitHub serve the purpose better?   We have frequently debated this multi-dimensional question.  And we should continue to do so: the answers may change over time (GitHub’s facilities are not static; and its increasing dominance is itself a cultural familiarity factor that simply was not the case five years ago).

 

Simon

 

From: Sven Panne [mailto:[hidden email]]
Sent: 19 December 2017 09:30
To: Herbert Valerio Riedel <[hidden email]>
Cc: Simon Peyton Jones <[hidden email]>; [hidden email] Devs <[hidden email]>
Subject: Re: Can't push to haddock

 

2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <[hidden email]>:

We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

 

I think this is a question of perspective: Having the master repository on GitHub doesn't mean you are in immediate danger or lose your "family jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that something goes wrong with GitHub, there is far more manpower behind it to fix that than for any self-hosted repository. And you can of course have some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco area... ;-)

 

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.

 

Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover;

 

This is by no means different than saying: "I want to run 'validate' in the commit hook, otherwise it's a big mess." We don't do this for obvious reasons, and what is the "big mess" if there is some incorrect submodule reference for a short time span? How is that different from somebody introducing e.g. a subtle compiler bug in a commit?

 

the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. [...]

 

Because the whole repository structure is overly complicated and simply hosting everything on GitHub would simplify things. Again: I'm well aware that there are tradeoffs involved, but I would really appreciate simplifications. I have the impression that the entry barrier to GHC development has become larger and larger over the years, partly because of very non-standard tooling, partly because of the increasingly arcane repository organization. There are reasons that other projects like Rust attract far more developers... :-/

</GrumpyMode>

 


_______________________________________________
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: Can't push to haddock

lonetiger


On Tue, Dec 19, 2017, 09:48 Simon Peyton Jones via ghc-devs <[hidden email]> wrote:

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.

Speaking for myself, I have no hostility towards GitHub, and there is no GHC-HQ bias against it that I know of.  If it serves the purpose better, we should use it.   Indeed that’s why I asked my original question.  I agree with your point that data may actually be safer in GitHub than in our own repo.   (And there is nothing to stop a belt-and-braces mirror backup system.)

 

These are just a few of the times github has been down in 2017 http://currentlydown.com/github.com compared to haskell.org http://currentlydown.com/haskell.org

Other third parties such as gitlab.com have suffered catastrophic data failures and by the very virtue of them being free means they don't owe you anything. 

I have nothing against github for small projects. I have nothing but hate for it for large ones. And I don't see that changing any time soon as everything they do seems to be half baked and the bare minimum 

The issue is: does GitHub serve the purpose better?   http://currentlydown.co have frequently debated this multi-dimensional question.  And we should continue to do so: the answers may change over time (GitHub’s facilities are not static; and its increasing dominance is itself a cultural familiarity factor that simply was not the case five years ago).


As is often the case in computing history. Dominance does not mean best nor fit for purpose. Supposedly switching to these cloud based CIs were suppose to solve all our issues. And to this day none of them are working not withstanding the massive amount of effort wasted to get them to work. 


Simon

 

From: Sven Panne [mailto:[hidden email]]
Sent: 19 December 2017 09:30
To: Herbert Valerio Riedel <[hidden email]>
Cc: Simon Peyton Jones <[hidden email]>; [hidden email] Devs <[hidden email]>


Subject: Re: Can't push to haddock

 

2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <[hidden email]>:

We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

 

I think this is a question of perspective: Having the master repository on GitHub doesn't mean you are in immediate danger or lose your "family jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that something goes wrong with GitHub, there is far more manpower behind it to fix that than for any self-hosted repository. And you can of course have some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco area... ;-)

 

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.

 

Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover;

 

This is by no means different than saying: "I want to run 'validate' in the commit hook, otherwise it's a big mess." We don't do this for obvious reasons, and what is the "big mess" if there is some incorrect submodule reference for a short time span? How is that different from somebody introducing e.g. a subtle compiler bug in a commit?

 

the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. [...]

 

Because the whole repository structure is overly complicated and simply hosting everything on GitHub would simplify things. Again: I'm well aware that there are tradeoffs involved, but I would really appreciate simplifications. I have the impression that the entry barrier to GHC development has become larger and larger over the years, partly because of very non-standard tooling, partly because of the increasingly arcane repository organization. There are reasons that other projects like Rust attract far more developers... :-/

</GrumpyMode>

 

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

_______________________________________________
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: Can't push to haddock

GHC - devs mailing list

Dominance does not mean best nor fit for purpose.

 

I could not agree more.  Dominance leads to familiarity, and that /is/ valuable.  And dominance suggests that it is fit for purpose for a large group.   But the question is: what is fit for our purposes?  

 

I think that is all that Herbert was getting at, and it’s the right question.   I’m making no assumptions about the answer, just saying that we should have no built-in bias (for or against) cloud solutions.

 

(And perhaps you are right to question my suggestion that a cloud repo is more reliable than a home-grown one.  I have no data.)

 

Simon

 

From: Phyx [mailto:[hidden email]]
Sent: 19 December 2017 10:08
To: Simon Peyton Jones <[hidden email]>
Cc: Herbert Valerio Riedel <[hidden email]>; Sven Panne <[hidden email]>; [hidden email] Devs <[hidden email]>
Subject: Re: Can't push to haddock

 

 

On Tue, Dec 19, 2017, 09:48 Simon Peyton Jones via ghc-devs <[hidden email]> wrote:

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.

Speaking for myself, I have no hostility towards GitHub, and there is no GHC-HQ bias against it that I know of.  If it serves the purpose better, we should use it.   Indeed that’s why I asked my original question.  I agree with your point that data may actually be safer in GitHub than in our own repo.   (And there is nothing to stop a belt-and-braces mirror backup system.)

 

These are just a few of the times github has been down in 2017 http://currentlydown.com/github.com compared to haskell.org http://currentlydown.com/haskell.org

 

Other third parties such as gitlab.com have suffered catastrophic data failures and by the very virtue of them being free means they don't owe you anything. 

 

I have nothing against github for small projects. I have nothing but hate for it for large ones. And I don't see that changing any time soon as everything they do seems to be half baked and the bare minimum 

The issue is: does GitHub serve the purpose better?   http://currentlydown.co have frequently debated this multi-dimensional question.  And we should continue to do so: the answers may change over time (GitHub’s facilities are not static; and its increasing dominance is itself a cultural familiarity factor that simply was not the case five years ago).

 

As is often the case in computing history. Dominance does not mean best nor fit for purpose. Supposedly switching to these cloud based CIs were suppose to solve all our issues. And to this day none of them are working not withstanding the massive amount of effort wasted to get them to work. 

 

 

Simon

 

From: Sven Panne [mailto:[hidden email]]
Sent: 19 December 2017 09:30
To: Herbert Valerio Riedel <[hidden email]>
Cc: Simon Peyton Jones <[hidden email]>; [hidden email] Devs <[hidden email]>


Subject: Re: Can't push to haddock

 

2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <[hidden email]>:

We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

 

I think this is a question of perspective: Having the master repository on GitHub doesn't mean you are in immediate danger or lose your "family jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that something goes wrong with GitHub, there is far more manpower behind it to fix that than for any self-hosted repository. And you can of course have some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco area... ;-)

 

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.

 

Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover;

 

This is by no means different than saying: "I want to run 'validate' in the commit hook, otherwise it's a big mess." We don't do this for obvious reasons, and what is the "big mess" if there is some incorrect submodule reference for a short time span? How is that different from somebody introducing e.g. a subtle compiler bug in a commit?

 

the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. [...]

 

Because the whole repository structure is overly complicated and simply hosting everything on GitHub would simplify things. Again: I'm well aware that there are tradeoffs involved, but I would really appreciate simplifications. I have the impression that the entry barrier to GHC development has become larger and larger over the years, partly because of very non-standard tooling, partly because of the increasingly arcane repository organization. There are reasons that other projects like Rust attract far more developers... :-/

</GrumpyMode>

 

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


_______________________________________________
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: Can't push to haddock

lonetiger
In reply to this post by Sven Panne-2


On Tue, Dec 19, 2017, 09:32 Sven Panne <[hidden email]> wrote:
2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <[hidden email]>:
We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

I think this is a question of perspective: Having the master repository on GitHub doesn't mean you are in immediate danger or lose your "family jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that something goes wrong with GitHub, there is far more manpower behind it to fix that than for any self-hosted repository. And you can of course have some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco area... ;-)

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.

Rust and Roslyn which also uses github both have essentially replicated phabricator features to github to make things manageable. People often ignore this on this off-handed remark that Rust uses github. This https://github.com/rust-lang-nursery/rust-forge/blob/master/infrastructure.md is part of the changes rust which has the backing of a major sponsor has to maintain to even start handling github. And I point out we have all of those just build into phabricator. 


And of all the tools I've used. Github has by far the worst interface to do code reviews. It's handling of rebases which will wipe all existing review comments when you push (collapsing them into oblivion) is very problematic. 

I'm not even sure they fixed the bug that pushing a later PR with the same branch name as an existing PR will permanently remove all review comments from the older PR. 

We're not special, we just don't want to trade a superior tool for a more popular but inferior one. 

Aside from being popular. Does github objectively have on redeeming feature?
 
Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover;

This is by no means different than saying: "I want to run 'validate' in the commit hook, otherwise it's a big mess." We don't do this for obvious reasons, and what is the "big mess" if there is some incorrect submodule reference for a short time span? How is that different from somebody introducing e.g. a subtle compiler bug in a commit?
 
the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. [...]

Because the whole repository structure is overly complicated and simply hosting everything on GitHub would simplify things. Again: I'm well aware that there are tradeoffs involved, but I would really appreciate simplifications. I have the impression that the entry barrier to GHC development has become larger and larger over the years, partly because of very non-standard tooling, partly because of the increasingly arcane repository organization. There are reasons that other projects like Rust attract far more developers... :-/
</GrumpyMode>

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

_______________________________________________
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: Can't push to haddock

Sven Panne-2
In reply to this post by lonetiger
2017-12-19 11:07 GMT+01:00 Phyx <[hidden email]>:
These are just a few of the times github has been down in 2017 http://currentlydown.com/github.com compared to haskell.org http://currentlydown.com/haskell.org [...]

I can't see any data for haskell.org on that page, apart from the fact that it is up right now. Furthermore, I very much question the data on currentlydown.com: According to it, Google, Facebook, YouTube, Yahoo! and Amazon were down on March 25th for roughly an hour. A much more probable explanation: currentlydown.com had problems, not the five of the biggest sites in the world. This undermines the trust in the rest of the outage reports a bit...

_______________________________________________
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: Can't push to haddock

lonetiger
Cool, then let's turn to media reports then such as https://techcrunch.com/2017/07/31/github-goes-down-and-takes-developer-productivity-with-it/ do you have one for git.haskell.org going down? 

On Tue, Dec 19, 2017, 10:56 Sven Panne <[hidden email]> wrote:
2017-12-19 11:07 GMT+01:00 Phyx <[hidden email]>:
These are just a few of the times github has been down in 2017 http://currentlydown.com/github.com compared to haskell.org http://currentlydown.com/haskell.org [...]

I can't see any data for haskell.org on that page, apart from the fact that it is up right now. Furthermore, I very much question the data on currentlydown.com: According to it, Google, Facebook, YouTube, Yahoo! and Amazon were down on March 25th for roughly an hour. A much more probable explanation: currentlydown.com had problems, not the five of the biggest sites in the world. This undermines the trust in the rest of the outage reports a bit...

_______________________________________________
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: Can't push to haddock

Sven Panne-2
2017-12-19 12:47 GMT+01:00 Phyx <[hidden email]>:
Cool, then let's turn to media reports then such as https://techcrunch.com/2017/07/31/github-goes-down-and-takes-developer-productivity-with-it/ do you have one for git.haskell.org going down? 

Of course this question is a classic example of "the absence of evidence is not the evidence of absence" fallacy, but anyway:

* Searchs ghc-devs@ for posts regarding Phabricator updates, Server moves, problems with arc... (not exactly all downtimes, but in effect of the incidents are the same)

I am not saying that the haskell.org infrastructure is bad, far from it, but it would be an illusion to think that it has a much higher effective uptime than GitHub. Furthermore: I don't think that the argument should revolve around uptime. We have a distributed version control system where people can happily work for an extended time span without *any* network at all, and the GHC source repository is not a financial application which would cause the loss of millions of dollars per minute if it's temporarily unavailable. The arguments should be about simplicity, ease of use, etc.

Anyway, for my part the discussion is over, there *is* more or less open hostility towards GitHub/more standardized environments here. Is it an instance of the common "not invented here" syndrome or general mistrust in any kind of organization? I don't know... :-/

_______________________________________________
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: Can't push to haddock

Brandon Allbery
In reply to this post by Sven Panne-2
On Tue, Dec 19, 2017 at 4:30 AM, Sven Panne <[hidden email]> wrote:
I think this is a question of perspective: Having the master repository on GitHub doesn't mean you are in immediate danger or lose your "family jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that something goes wrong with GitHub, there is far more manpower behind it to fix that than for any self-hosted repository. And you can of course have some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco area... ;-)

You're also assuming github doesn't suddenly pull a SourceForge (or a Gitorious for that matter). Business cares not what it steamrolls in the name of profit.

I fail to understand why, with multiple examples of the folly of this belief out there, people are still willing to bet on *this* company being *different* from all others and absolutely safe to trust.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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: Can't push to haddock

Gershom Bazerman
In reply to this post by GHC - devs mailing list
> You're also assuming github doesn't suddenly pull a SourceForge (or a
> Gitorious for that matter). Business cares not what it steamrolls in the
> name of profit.
>
> I fail to understand why, with multiple examples of the folly of this
> belief out there, people are still willing to bet on *this* company being
> *different* from all others and absolutely safe to trust.

What the heck is everyone arguing over? The initial statement was that
even if we moved everything to github "We'd need mirroring anyway".
That's it! There's no either/or involved. Just a statement that when
you have data in one location, no matter how trustworthy, you want a
backup as well. And ideally you want the backup under your control.

We can debate moving anything anywhere all we want, but the idea that
stuff should also be backed up, regardless, in a source not under
third-party control, seems inoffensive and besides the point.

--Gershom
_______________________________________________
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: Can't push to haddock

Manuel M T Chakravarty-4
Thank you for that word of reason.

(In addition to your very well stated point, the whole point of Git is that it is a *distributed* RCS. I don’t think, anything less than a full scale planetary nuclear war could really wipe out the GHC source code at this point.)

Manuel

> 20.12.2017 05:02 Gershom B <[hidden email]>:
>
>> You're also assuming github doesn't suddenly pull a SourceForge (or a
>> Gitorious for that matter). Business cares not what it steamrolls in the
>> name of profit.
>>
>> I fail to understand why, with multiple examples of the folly of this
>> belief out there, people are still willing to bet on *this* company being
>> *different* from all others and absolutely safe to trust.
>
> What the heck is everyone arguing over? The initial statement was that
> even if we moved everything to github "We'd need mirroring anyway".
> That's it! There's no either/or involved. Just a statement that when
> you have data in one location, no matter how trustworthy, you want a
> backup as well. And ideally you want the backup under your control.
>
> We can debate moving anything anywhere all we want, but the idea that
> stuff should also be backed up, regardless, in a source not under
> third-party control, seems inoffensive and besides the point.
>
> --Gershom
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
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: Can't push to haddock

Manuel M T Chakravarty-4
In reply to this post by GHC - devs mailing list
I think, what Sven is getting at here —and I do have to say, I concur— is that there is a bit of NIH (Not Invented Here) syndrome in parts of the Haskell community. I think, part of it is just inertia and the desire to keep things the same, because that is easier and more familiar.

One aspect that complicates this discussion significantly is that GHC dev has developed certain work arounds and ways of doing things, where third party infrastructure seems lacking in features, because it doesn’t support all these quirks. However, it turns out that if we are only prepared to change our workflow and processes to align with modern software development practices, many of theses ”features” aren’t actually necessary. We have seen quite a bit of that in the CI discussion. 

I am not writing this to blame anything or anybody. I think, it is a normal part of a healthy process of change. However, it complicates the discussion as people get hung up on individual technicalities, such as this or that feature is missing, without considering the big picture.

Generally, I think, a worthwhile golden rule in ops is that custom infrastructure is bad. It creates extra work, technical debt, and failure points. So, IMHO the default ought to be to use 3rd part infrastructure (like GitHub) and only augment that where absolutely necessary. This will simply leave us with more time to write Haskell code in GHC instead of building, maintaining, and supporting GHC infrastructure. 

Cheers,
Manuel

19.12.2017 20:47 Simon Peyton Jones via ghc-devs <[hidden email]>:

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.

Speaking for myself, I have no hostility towards GitHub, and there is no GHC-HQ bias against it that I know of.  If it serves the purpose better, we should use it.   Indeed that’s why I asked my original question.  I agree with your point that data may actually be safer in GitHub than in our own repo.   (And there is nothing to stop a belt-and-braces mirror backup system.)
 
The issue is: does GitHub serve the purpose better?   We have frequently debated this multi-dimensional question.  And we should continue to do so: the answers may change over time (GitHub’s facilities are not static; and its increasing dominance is itself a cultural familiarity factor that simply was not the case five years ago).
 
Simon
 
From: Sven Panne [[hidden email]] 
Sent: 19 December 2017 09:30
To: Herbert Valerio Riedel <[hidden email]>
Cc: Simon Peyton Jones <[hidden email]>; [hidden email] Devs <[hidden email]>
Subject: Re: Can't push to haddock
 

2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <[hidden email]>:

We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

 

I think this is a question of perspective: Having the master repository on GitHub doesn't mean you are in immediate danger or lose your "family jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that something goes wrong with GitHub, there is far more manpower behind it to fix that than for any self-hosted repository. And you can of course have some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco area... ;-)

 

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.

 

Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover;

 

This is by no means different than saying: "I want to run 'validate' in the commit hook, otherwise it's a big mess." We don't do this for obvious reasons, and what is the "big mess" if there is some incorrect submodule reference for a short time span? How is that different from somebody introducing e.g. a subtle compiler bug in a commit?

 

the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. [...]

 

Because the whole repository structure is overly complicated and simply hosting everything on GitHub would simplify things. Again: I'm well aware that there are tradeoffs involved, but I would really appreciate simplifications. I have the impression that the entry barrier to GHC development has become larger and larger over the years, partly because of very non-standard tooling, partly because of the increasingly arcane repository organization. There are reasons that other projects like Rust attract far more developers... :-/

</GrumpyMode>

 

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


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