[Haskell-cafe] possible bug in latest hackage Elf (Elf-0.27)

[Baojun Wang]

Many thanks for the input, I've sent email to the maintainer, hopefully
could get reply soon :)


Best Regards
baojun


On Thu, May 15, 2014 at 7:00 AM, Anthony Cowley <acowley at seas.upenn.edu>wrote:

>
> > On May 15, 2014, at 5:18 AM, Sven Panne <svenpanne at gmail.com> wrote:
> >
> > 2014-05-15 9:30 GMT+02:00 Roman Cheplyaka <roma at ro-che.info>:
> >> If there's no response, then you have two choices:
> >
> > Actually three: Fix things locally until the "official" package is fixed.
> >
> >> * request package maintainership, which will take several weeks
> >
> > I really hope that this will take months, not weeks, see the other
> discussion
> >
> >> * fork the package (i.e. upload your patched version to hackage under a
> >>  different name)
> >
> > This proposal worries me quite a bit, because if everybody follows
> > that advice, it will turn Hackage into a chaotic collection of
> > packages with various degrees of being fixed/maintained/etc. Imagine a
> > package 'foo', which needs a fix, and several pepole think it's a good
> > idea to fork and fix the issue at hand. Now we have 'foo', 'foo-XY',
> > 'foo-my-cool-acronym', ... Of course people normally have no incentive
> > to really take over maintainership for 'foo', they just want a working
> > 'foo' right now for their own project. Later the real maintainer
> > re-appears after vacation/sabbatical/whatever, fixes 'foo', and
> > continues to work on it, adding new features. Now somebody new comes
> > to Hackage to see if there is already a package for some use case, and
> > finds 'foo', 'foo-XY', 'foo-my-cool-acronym', ... Then it takes some
> > non-trivial detective work to find out which packages are actually
> > dead (again) and which is the real one. => Chaos IMHO.
> >
> > In a nutshell: If you are really in a hurry, fix things locally.
> > Hackage is not the place to fork like hell.
>
> But we do need a mechanism to deal with name expansion. Many of us would
> prefer to make package name usurpation a slow, forgiving process, but we
> should then contend with the fact that such a policy adds to the rate at
> which new packages are uploaded. If search results display, and can be
> sorted by, information regarding number of downloads, downloads in the last
> year, and latest upload date, we will be suggesting which of these
> variations a new user should consider. Pair this with a slow name
> reclaiming process, and we won't have to always consider perpetuity when
> coming up with package names.
>
> Preferably packages would also come with some sort of UUID independent of
> a user-friendly name so that they could exist on hackage without blocking
> new uses of a good name if one development has permanently stalled.
>
> Anthony
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140515/d9e43a0e/attachment.html>