2016-12-13 03:51:38 +0000hexagoxel(~hexagoxel@p4FCCDA14.dip0.t-ipconnect.de) (Ping timeout: 264 seconds)
2016-12-13 03:52:31 +0000lspitzner(~lspitzner@p200300798F187000021E33FFFE2231E9.dip0.t-ipconnect.de) (Ping timeout: 258 seconds)
2016-12-13 03:54:16 +0000hexagoxel(~hexagoxel@p200300798F1FDF00021E33FFFE2231E9.dip0.t-ipconnect.de)
2016-12-13 03:58:17 +0000lspitzner(~lspitzner@p5B29A6C3.dip0.t-ipconnect.de)
2016-12-13 04:01:26 +0000refold(~refold@188.172.147.158)
2016-12-13 04:36:20 +0000edsko(~quassel@23.104.209.182) (Read error: Connection reset by peer)
2016-12-13 04:37:17 +0000edsko(~quassel@23.104.209.182)
2016-12-13 05:24:35 +0000begriffs(~begriffs@104.156.228.157) (Quit: Leaving...)
2016-12-13 06:31:28 +0000 <ezyang> hmm, I wonder if I should put some Backpack helper packages on Hackage, or only as candidates, or on a private mirror
2016-12-13 07:08:28 +0000edvorg(~edvorg@host-46-50-214-114.bbcustomer.zsttk.net)
2016-12-13 07:08:54 +0000 <sclv> do you intend them to be eventually used generally?
2016-12-13 07:08:59 +0000 <sclv> or are they only for demo purposes?
2016-12-13 07:09:21 +0000 <sclv> if the former, then i see no problem with putting them up with a warning about their limited use now, with the expectation that they'll develop over time...
2016-12-13 07:09:50 +0000 <ezyang> Former
2016-12-13 07:10:43 +0000 <ezyang> but I know hvr gets touchy when people spam the index
2016-12-13 07:12:00 +0000 <hvr> ezyang: :-) (yes... see https://github.com/haskell/hackage-server/issues/461 )
2016-12-13 07:13:21 +0000 <hvr> ezyang: fwiw, I recently had a chat with tdammers and sclv, and the conclusion was removing that tension would be quite easy if we had a 2nd index
2016-12-13 07:14:13 +0000 <ezyang> as in, another hackage, or another tarball
2016-12-13 07:14:14 +0000 <hvr> ezyang: one you'd have to opt-in as a client, and opt-out as an uploader
2016-12-13 07:14:42 +0000 <hvr> ezyang: another tarball url
2016-12-13 07:14:46 +0000 <ezyang> if it's not written down it doesn't exist :P
2016-12-13 07:14:53 +0000 <hvr> ezyang: and we're already half-way there
2016-12-13 07:15:21 +0000 <hvr> ezyang: we already have the candidate feature, we'd have to polish & complete it up
2016-12-13 07:16:24 +0000 <hvr> ezyang: e.g. have http://hackage.haskell.org/packages/candidates/ create an index tarball, symlink the tarball under an urlpath offset
2016-12-13 07:16:38 +0000 <hvr> w/ the source-tarballs
2016-12-13 07:16:39 +0000 <hvr> etc
2016-12-13 07:17:23 +0000 <hvr> put simply, integrate candidates better with the rest
2016-12-13 07:23:42 +0000 <hvr> ezyang: another benefit is of course, that trustees can mostly ignore the 2nd index and focus on the packages in the primary index
2016-12-13 07:26:48 +0000 <ezyang> hvr: how do you keep them consistent?
2016-12-13 07:26:57 +0000 <hvr> ezyang: what do you mean?
2016-12-13 07:27:05 +0000 <ezyang> as in, if a tarball shows up in both
2016-12-13 07:27:33 +0000 <hvr> a) wouldn't be a big deal, cabal new-build uses sha256s b) there's already an issue about that
2016-12-13 07:28:06 +0000 <hvr> ezyang: https://github.com/haskell/hackage-server/issues/558
2016-12-13 07:28:36 +0000 <hvr> see the boldfaced invariant in the middle of the description :-)
2016-12-13 07:29:37 +0000 <ezyang> I hope you never edit package descriptions in candidate ;)