[arch-haskell] How to determine whether a package is in or out in [haskell]?
magnus at therning.org
Fri Nov 11 21:42:52 CET 2011
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
> 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
> 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?
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
Size: 198 bytes
Desc: not available
More information about the arch-haskell