On Fri, Nov 11, 2011 at 06:37:14PM +0100, Nicolas Pouillard wrote: >On Thu, Nov 10, 2011 at 10:07 PM, Magnus Therning <mag...@therning.org> wrote: >> Now we have 300+ packages in [haskell]. It's starting to be a >> large set, and the time required to build when something changes is >> starting to really be felt now. So I would like to start a >> discussion on how we should decide what criteria to use when adding >> a package, and equally important, what criteria to use when >> dropping a package. >> >> My _impression_ is that additions have been a bit willy-nilly. >> Guided only by what the maintainers fancy at the moment. I also >> don't think that we've ever dropped a package, ever. >> >> I feel it's important to me to know that the resources I put into >> ArchHaskell is appreciated, and every added package increases the >> resources required. I therefore would like to know that each and >> ever package in [haskell] is there for a good reason. >> >> I feel I need to bring this up because there are a few packages in >> [haskell] that I suspect are there, but aren't widely used. To >> point fingers, the chief reason is Agda :) This is a package that >> has a mere 13 votes in AUR, and it takes more than an hour to build >> it on my laptop (about 70 minutes to be more precise). On each >> platform! > > Why doing this kind of builds on a laptop? I mean if we had no other > way... I'm a using fast desktop host I have access to.
Because I don't have root access on any other system than my laptop. > BTW I have all the packages built and was ready to push them when I > saw you already updated half of them (x86_64) and still no commit on > git. > > Can I push mine? > > Moreover I'm not fond of this kind of race. Neither am I, but I see no way easy way of addressing that. I'm a strong believer in only pushing changes once they build, and the only way of making sure of that is to make the build. Building ~50 packages takes quite a while. >> So, what are our options when it comes to deciding what's in and >> what's out? Any thoughts? > > I'm not for selecting a few highly used packages, but as much as > possible working packages that are needed at some point. To do so we > must improve our tools and workflow to deal seamlessly with the > amount of packages. Please define "working packages" and what you mean by "needed at some point" (needed by whom, how do we find out that there is a need, and how do we find out that if the need goes away?). As you might guess I don't think what you suggest is objective enough. I would like to avoid the situation where we collect packages that largely go unused, and therefore add little value to the users, while eating resources for the maintainers. > So for me we move out broken packages that we cannot quickly fix if > they are not much used. How do we find out if they aren't used? >> Oh, and can I please drop Agda in the meantime? ;) > > I'm not in favor of that. I'm guessing you are using it then, right? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay
pgpGLRWPYavAi.pgp
Description: PGP signature
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell