Hackage 2 status

Ian Lynagh ian at well-typed.com
Mon Jul 2 13:25:29 CEST 2012


Hi all,

I'm planning to spend some time, on behalf of the Industrial Haskell
Group, working on Hackage 2 in the coming weeks.

As such, I've been trying to work out what the blockers are in terms of
actually getting the hackage 2 server live. I've started from the
"Current TODOs" section of
    http://hackage.haskell.org/trac/hackage/wiki/HackageDB/2.0
and the rest of this mail is a brief description of what I've found out,
and my conclusions.

Active tickets against Hackage 2
--------------------------------

There are currently 8 tickets:

#911  Package uploading is completely unsecured                 high
#916  Verify that HTTP interface is fully/properly implemented  high
#918  Working documentation builder                             high
#426  .cabal files should be stored next to tarballs,
      potentially overriding in-tarball version                 normal
#913  New HTML theme                                            normal
#914  Fix acid-state usage                                      normal
#919  hackage-mirror should handle errors more gracefully       normal
#915  Convert to modular use of type-safe URLs                  low

Now #913 I assume is not a blocker. #919 I assume is also not a blocker.
And #914 and #915 are improvements to the internals, so presumably also
not blockers. #426 is not supported by Hackage 1 as far as I can see, so
is not a blocker as it is not a regression.

So that leaves 3 tickets as blockers:

#911: We need to do something here. With Hackage 1, it takes manual
approval before you can upload packages, and at the very least Hackage 2
should match that. I have the impression that that is already possible
(by restricting package upload to a group, and requiring accounts to be
added to that group by an admin), but I haven't confirmed that yet.

#916: At the very least, Hackage 2 needs to support URLs that Hackage 1
supported (unless a conscious decision has been made not to). Ideally we
would get the URLs right on the initial release, so that people don't
start using the wrong ones. Doesn't sound hard, so may as well do before
the switchover.

#918: This is the main missing functionality currently missing from the
user's point of view.

HackageDB
---------

I don't think there are any blockers on this page.

HackageToDo
-----------

Package builds:       Not a regression, so not a blocker.
Haddocking:           See #918 above.
Hoogle database:      Not a regression, so not a blocker.
HsColour:             Hackage 1 supports this. Should be done as part of #918.
Testing builds:       Not a regression, so not a blocker.
Running testsuites:   Not a regression, so not a blocker.
Packages properties:  Meta info is already available, so not a blocker.
Queries:              Not a regression, so not a blocker.
Show respository:     Small regression; May as well fix.
README markup etc:    Not a regression, so not a blocker.
Uploads:              All sub opints either mentioned already or new features.
                      Not blockers.
DOAP:                 Not a regression, so not a blocker.
Gateways:             Should support the existing "Distributions" files.

Documentation needs love
------------------------

I'm not sure whether user or developer documentation is intended here.
Without more details, I'll treat this as not a blocker.

Further context
---------------

I didn't see any other blockers in the old mails linked to.

Conclusion
----------

I think the following are the blockers for deploying Hackage 2:

* #911 upload perms; may be good enough already
* #916 check URLs are OK
* #918 build haddock (and HsColour) docs
* Show source respository on package pages
* Support the existing "Distributions" files, and show info on package pages

(plus enough testing to give us confidence in it, of course).

Does that match other people's opinions? Did I miss anything?


Thanks
Ian




More information about the cabal-devel mailing list