On Mon, Jul 02, 2012 at 08:14:01PM +0100, Duncan Coutts wrote:
> On Mon, 2012-07-02 at 12:25 +0100, Ian Lynagh wrote:
>
> > 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
I forgot that the bug tracker had moved to github. So actually these
are now:
* #901 upload perms; may be good enough already
* #906 check URLs are OK
* #908 build haddock (and HsColour) docs
and are the tickets marked "important" or "urgent" on
https://github.com/haskell/cabal/issues?labels=hackage2&page=1&state=open
> > * Show source respository on package pages
>
> Should be easy to port that from the old code.
I've filed #965 (hackage2, important) for that.
> > * Support the existing "Distributions" files, and show info on package pages
>
> I advocated at the time the feature was added that it should be done
> differently so that the hackage server does not poll some url, but
> people in charge of distros push instead. I think it would not be a
> blocker to not implement the distribution info system as it is now and
> when eventually spending the time to implement it, switch to doing it in
> a more sensible way.
OK, I won't treat that as a blocker then.
> > (plus enough testing to give us confidence in it, of course).
>
> One of the main things here is adding tests that the database
> dump/restore mechanism round trips correctly.
#966 (hackage2, important) filed.
> Something to keep in mind is memory usage.
Will do, but currently I don't think this is a blocker for deploying
2.0.
Thanks
Ian
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
