[Nix-dev] Stackage Support Will Be Discontinued

[Daniel Peebles]

Yeah. I think there's a tough balance to strike in OSS between feedback and
gratitude, and most of us have been on both wrong sides of it in the past.

Peter is putting all this work in for free and has almost single-handedly
been responsible for drawing a sizable chunk of the Haskell community
(including me) to the Nix world. That is awesome. He's also obviously free
to pour his free time into whichever direction he thinks is best for the
project (or not put any time in at all, obviously).

At the same time, feedback is important to all creative processes, even
when critical. What we have here is two prominent haskellers saying that
the changes that Peter is proposing will make the system less useful to
them, and that they predict it'll also make the system less useful to
others with similar workflows. I think that feedback, even if critical, is
extremely valuable, and should factor into Peter's decision. I realize it
can be tough to separate out the negativity from the gratitude but we're
all in this boat together and if people disagree, it's because they all
want the project to succeed.

Anyway, most of us are experienced in open source work and saying "you can
just fork it" is roughly equivalent to a dismissive wave of the hand in
this context.

I see a few possible outcomes here:

   1. Peter is swayed by Anthony and Thomas's arguments, and decides to
   keep (parts of?) stackage support around.
   2. Peter is swayed by their arguments, but still doesn't use stackage
   himself and with limited free time is unwilling to maintain support
   himself. He and other interested parties figure out a good way to split
   responsibilities so that people who care about stackage can still maintain
   a first-class (i.e., non-forked) experience for it, and he can focus on
   other workflows that interest him more.
   3. Peter is unswayed by their arguments and doesn't think stackage
   belongs in mainline nixpkgs, effectively forcing some sort of forked
   workflow (or Anthony and Thomas and others like them to do their Haskell
   work outside of Nix)
   4. Everyone gets pissed off and thinks nobody appreciates/understands
   their work/feedback and walks away from this discussion feeling drained and
   less willing to contribute to Nix.

I'd personally prefer #1 or #2. Let's do our best to avoid #4 though?


On Fri, Jun 10, 2016 at 7:42 AM, Thomas Tuegel <ttuegel at gmail.com> wrote:

> Hi Peter and Anthony,
>
> On Thu, Jun 9, 2016 at 4:04 PM, Peter Simons <simons at nospf.cryp.to> wrote:
> > Hi Anthony,
> >
> >  >> [What is] a concrete use case that works for you today but that
> >  >> won't work after LTS-4 has been dropped?
> >  >
> >  > Someone who has a project that works with package versions in LTS-4,
> >  > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to
> >  > LTS-4 in their shell.nix for haskell packages.
> >
> > Oh, but you can absolutely do that! You can extend the set of available
> > packages to your heart's content and you can compose package sets that
> > provide any combination of versions as you please. The Haskell
> > infrastructure in Nix gives you that ability.
>
> Let me remark on this non-sequitor. Of course Anthony or I or anyone
> else could always extend or fork Nixpkgs to do whatever we want! I
> don't think anyone with experience in open source software needs this
> to be pointed out to them. That's obviously not Anthony's complaint,
> which is rather
>
> The choice to discontinue Stackage support makes Nixpkgs significantly
> less useful to some of our users.
>
> It seems disingenuous to pretend that some other complaint is being
> made, for the sake of summarily dismissing that complaint. As
> *volunteer* distribution maintainers, we are free to consider or
> disregard complaints at will; there is no need to misrepresent what
> people are saying.
>
> It is completely legitimate to take the position that the benefit (to
> our users like Anthony) of keeping Stackage does not outweigh the
> resource cost to Nixpkgs or the technical cost of finding a more
> efficient way to include those packages. This is obviously the
> position that the Haskell infrastructure and Nixpkgs maintainers have
> reached. Stating outright that they will not be swayed saves our users
> time and frustration because they can immediately seek solutions
> outside Nixpkgs.
>
> Regards,
> Thomas
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160610/a640078a/attachment-0001.html>