Re: [arch-haskell] How to determine whether a package is in or out in [haskell]?

On Fri, Nov 11, 2011 at 06:37:14PM +0100, Nicolas Pouillard wrote:

On Thu, Nov 10, 2011 at 10:07 PM, Magnus Therning 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: magnus@therning.org jabber: magnus@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