Drop Agda and adopt Leksah and qtHaskell. =)

An automatic and distributed building and testing system would he useful here.

But "arch-haskell" is supposed to be the maintainer of qtHaskell, at least on AUR. Are you going to disown it in AUR? BTW, it is currently it is broken for me.

On 2011-Nov-10, Felipe Almeida Lessa wrote:

On Thu, Nov 10, 2011 at 7:07 PM, Magnus Therning wrote:

...

So, what are our options when it comes to deciding what's in and what's out?  Any thoughts?

One possibility is looking at the most downloaded packages on Hackage.

... Are the download statistics from Hackage publicly available? And if so, where?

Cheers,

-- Felipe.

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

-- Gregory D. Weber, Ph. D. : Associate Professor of Informatics / \ Indiana University East 0 : Tel. (765) 973-8420; FAX (765) 973-8550 / \ http://mypage.iu.edu/~gdweber/ 1 []

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

On Fri, Nov 11, 2011 at 07:07:26PM -0800, Leif Warner wrote:

On Thu, Nov 10, 2011 at 1: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!

FWIW, I could help out with builds these days, if need be. My work equipment is a new 4-core (8 w/ HT) machine w/ 8 GB RAM + SSD drive.

It would be excellent if more people could work on keeping [haskell] up-to-date :) However, splitting updating the database and the building of packages is likely to be a bit painful. So far my experience is that updating packages to a buildable state often requires a few iterations of modifying patch files and attempting builds. If each such iteration requires communication it's likely to drag out quite a bit. The ideal would be a build server really. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay

Regarding what to put in the repository, I would use AUR and aurvote. I (and whoever want to) could maintain some aur package orphaned by archhaskell user. Packages that take some vote go in arch-haskell. I don't know how many people use yaourt, but I do and I would like to have as many updated haskell package in AUR as possible, if we can't have all of them in arch-haskell. Cheers, Fabio 2011/11/13 Fabio Riga

Hello,

2011/11/12 Magnus Therning

...

It would be excellent if more people could work on keeping [haskell] up-to-date :)

However, splitting updating the database and the building of packages is likely to be a bit painful. So far my experience is that updating packages to a buildable state often requires a few iterations of modifying patch files and attempting builds. If each such iteration requires communication it's likely to drag out quite a bit. The ideal would be a build server really.

/M

why should we drop packages? Unless we are running out of space on the repository server we shouldn't. So I think we should find a solution to decentralize the building process. So a build server could be okay. Is it a problem to have a maintainer that check *some* packages, and not everything? The main maintainer should only put everything together, maybe periodically, so the others know when to submit updates and when to wait for the next one.

Are you sure this will be more painful than build everything by your own on your laptop?

Fabio

On Sun, Nov 13, 2011 at 19:27, Bernardo Barros wrote:

Yes, disown those broken/outdated packages so other people can fix them...

I will, as soon as I have looked at some ways to disown that many packages conveniently. /M -- Magnus Therning                      OpenPGP: 0xAB4DFBA4 email: magnus@therning.org   jabber: magnus@therning.org twitter: magthe               http://therning.org/magnus

Hi Magnus, sorry for my late answer on this and for my bad English... I'll try to be more clear. IMHO, the ArchHaskell project should be a very big repository with most up-to-date packages from hackage. Now, it seems to me that you are doing all the work, so it's not possible for this project to grow (actually you proposed to drop some packages!). It seems to me that the method you're adopting doesn't allow a real help from others: some times ago I try to help, run some update in cblrepo, build all the updates and pushed the changed cblrepo.db file to you. I assume that you had to build all packages again. And this is a waste of time. My idea is to use cblrepo in another way: now cblrepo.db file has about 300 packages. We should split this file in 4 or 5 groups of packages, 1 group (the main one) with common, more basic packages and the others divided by category (for example: net, dev, etc.). We should group the packages, so that one group has dependencies only in itself or in main group. So let's say, for instance, that you work on the main package and I take the network. I will create a cblrepo db that *depends* on your: if there are updates in the network, I'll do the updates, and send to you (or upload to the server) the resulting packages; when there are changes in the main you'll do your job, and I will bump packages that depends on the ones updated by you. If I understand well, that's the way you deal with DistroPkgs. So my cblrepo db will include packages belonging to your cblrepo as * DistroPkg*. This will share the long compiling work between us. The downside is that we *must* be in sync: you have to tell me witch package you are updating and I can't wait long before update, or packages will be broken. I would take the risk, anyway, there are already broken packages, but that's depends on another problem, I will discuss this on the proper thread... A script should automate the process of finding, inserting and compiling updates, i.e. should wrap cblrepo into something more easy. I'm working on this. Bye, Fabio 2011/11/14 Magnus Therning

...

why should we drop packages? Unless we are running out of space on the repository server we shouldn't. So I think we should find a solution to decentralize the building process. So a build server could be okay. Is it a problem to have a maintainer that check some packages, and not everything?

Sure, we could use a build server. There's a standing request for anyone to step up with an offer of a system that we can use. Ideally with a web interface so we can submit source packages, together with a build list, and then just check in to get the results later on. In the meantime however, we're stuck with building things on whatever systems we have access to.

I'm not sure I understand your question about maintainers, but I'll take a stab at answering anyway. Let me know if I got you all wrong :)

Sorry. I'll try to improve my English! :-)

Hackage moves very quickly, and it's very common that updating a single package requires that a few others are updated as well. Due to the nature of the code that GHC spits out we also need to bump the release of all packages that depend on an updated package. The end result is that it's very rare that I can update a single package, and I don't I've ever been able to build just a single package due to an update. Given this I don't see much value in having maintainers for subsets of ArchHaskell.

...

The main maintainer should only put everything together, maybe periodically, so the others know when to submit updates and when to wait for the next one. Are you sure this will be more painful than build everything by your own on your laptop?

I don't understand what you mean here, would you mind giving an example?

/M

-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus