cabal-devel

Download

cabal-devel@haskell.org

July 2012

9 participants
32 discussions

Hackage 2 status
by Ian Lynagh 03 Jul '12

03 Jul '12

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

4 6

hackage2 account approvals (Re: Hackage 2 status)
by Conrad Parker 03 Jul '12

03 Jul '12

On 3 July 2012 03:14, Duncan Coutts <duncan.coutts(a)googlemail.com> wrote: > On Mon, 2012-07-02 at 12:25 +0100, Ian Lynagh wrote: >> Hi all, >> >> I'm planning to spend some time, on behalf of the Industrial Haskell >> Group, working on Hackage 2 in the coming weeks. > > [..] > >> 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. > > Right, I don't think we need to do any more than make sure uploaders are > in the appropriate group. It *should* currently be the case that only > accounts in the package group can upload, and the first time you upload > a new named package then you get added as the initial member of the new > package group. > > Currently for testing purposes anyone can register an account and can > then upload new packages. We have two options here: restrict account > creation to be manual like in hackage 1, or add a new system-wide > "uploaders" group for accounts that are authorised to upload new > packages and have a manual admin step to add people to the uploaders > group. The latter will allow for registered users who are not uploaders > which would be useful later to allow things like non-anonymous > commenting etc. I think we should avoid manual approvals; I know several people who have excellent, working, used in-production, cabalified Haskell code but for whatever reason they are reluctant to request an account -- however they have code on github. Allowing random users to upload code only really becomes a problem when poorly named or insecure packages pollute the global namespace; perhaps admin approval should only be on global naming, not on account creation and upload. Conrad.

2 1