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

[Magnus Therning]

On Fri, Nov 11, 2011 at 06:37:14PM +0100, Nicolas Pouillard wrote:
>On Thu, Nov 10, 2011 at 10:07 PM, Magnus Therning <magnus at 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: magnus at therning.org   jabber: magnus at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/arch-haskell/attachments/20131012/2a645ca7/attachment.sig>