[Haskell-cafe] RFC: removing “alternative installation methods” from haskell.org (or finding them owners)

[Artem Pelenitsyn]

As was mentioned on a GitHub thread related to this topi, Rust has a great
example of how to do it,
I encourage everyone to take a look:
https://www.rust-lang.org/tools/install
i.e. Alternative methods are mentioned at the bottom as a link to some sort
of broader language manual.
The main website shouldn't be a wiki page for "known methods", it should be
a safest trampoline into the
language for newcomers. In the same line, saying that moving away this list
from this website deprives
current users of these methods is nonsense: if you use a method and it
works for you — great! Nothing
will change for you when (if) the Downloads page changes. A method that you
are most used to has
nothing to do with how we must present a gate to the language to newcomers,
who are the primer clients
of this page.

--
Cheers, Artem

On Sun, 3 Apr 2022 at 17:35, MigMit <migmit at gmail.com> wrote:

> I think I remember myself as an inexperienced user. I might've walked away
> from Haskell, if I was given an instruction like "to install thing X, first
> install thing A, then use it to install think K, and then use that to
> install thing X". The longer the way between becoming curious about
> something and actually producing an executable, the less new users you have.
>
> > On 3 Apr 2022, at 23:24, Tom Ellis <
> tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> >
> > On Sun, Apr 03, 2022 at 02:58:03PM -0400, Ivan Perez wrote:
> >> On Sun, 3 Apr 2022 at 14:48, Tom Ellis <
> tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> >>> Yet, their work has not been (recently) confirmed working by those
> >>> responsible for maintaining www.haskell.org, nor do we have the
> >>> resources to perform such confirmations.
> >>
> >> You (I don't mean necessarily you personally) are still making a
> decision
> >
> > So far no decision has been taken.  The Haskell.org committee has a
> > made a proposal and is seeking community feedback.  Action will be
> > taken based on consideration of the feedback received.
> >
> >> based on your lack of resources to determine if something is up to
> date. Is
> >> not that they are not up to date, it's that you don't know if they are
> (and
> >> you know that you don't know, since you are acknowledging it). But you
> are
> >> still willing to not list them.
> >
> > You are correct that the proposal is to err on the side of removing
> > information that may be unhelpful, rather than keeping information
> > that may be helpful.  I prefer the former since it seems to strike a
> > good balance between providing a clear onboarding path to
> > inexperienced users, providing a uniform onboarding path to make
> > providing support easier, providing sufficient experieced users with a
> > wide range of options, and allowing maintenance by a small group of
> > volunteers with not much time on their hands.
> >
> > That said, the current downloads page says
> >
> > "EPEL 5 and 6 have ghc-7.0.4 and cabal-install-0.10.2"
> >
> > and I know for a fact that is about five years out of date.  Indeed it
> > seems that EPEL 5 was EOLed in 2017
> >
> > https://fedoramagazine.org/the-end-of-the-line-for-epel-5/
> >
> >> Since people are putting a lot of effort into maintaining that work, by
> >> ignoring that (due to lack of resources) you are contributing to that
> >> compound effect I was describing. They are doing this for the community,
> >> but the community seems to ignore them.
> >>
> >> I think it's more fair to acknowledge those efforts, to let people list
> >> what they think is useful for them.
> >
> > I'm very much in favour of letting people list what they think is
> > useful for them, and to promote the OS packaging work that people have
> > put a lot of effort in to.  We simply need to find volunteers who are
> > willing to put in the effort to keep the information we provide
> > correct, up to date, and thus, useful.  Part of this proposal is to
> > reach out to potential volunteers.  Would you be willing to volunteer?
> > If so then please introduce yourself at the following GitHub
> > discussion:
> >
> > https://github.com/haskell-infra/www.haskell.org/discussions/169
> >
> >> If the problem is understanding if those methods still work, perhaps
> what
> >> we need is a mechanism to keep track of installation methods available
> and
> >> the last time they were verified. That detailed info can be used to keep
> >> the page up to date.
> >
> > That sounds like a great idea. Would you be willing to implement that
> > idea?
> >
> > Tom
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220403/5b342580/attachment.html>