On 1 November 2011 03:43, Alexander Kjeldaas wrote:

On 31 October 2011 17:22, Yitzchak Gale wrote:

...

Gregory Crosswhite wrote:

...

could [Hackage] have a feature where when a working package breaks with a new version of GHC the author is automatically e-mailed?

This would be nice. However, there would have to be a way for it to be turned on and off by the author. (Spam is not nice.)

How about sending an email to haskell-package-<packate-name>@haskell.org, and then people can join that mailing list if they are interested in that sort of stuff?  Mailman is good at doing subscribe and unsubscribe.

+1 I like this because it is opt-in for the maintainer, and also allows anyone else who is interested in the package to track it. Per-package RSS updates of build failures would also be useful. Conrad.

Yitzchak Gale writes:

Gregory Crosswhite wrote:

...

could [Hackage] have a feature where when a working package breaks with a new version of GHC the author is automatically e-mailed?

This would be nice. However, there would have to be a way for it to be turned on and off by the author. (Spam is not nice.)

This is where it stranded the last time, IIRC. That sentiment makes me a bit uneasy; so you are the official maintainer of a package on Hackage, but you do not want to hear about it when it fails to compile? To me, this raises the question whether you should take on the responsibility as maintainer at all. Ideally, I think Hackage should avoid being a dumping ground for non-working code, and I think the key to high quality software is having active maintainers for each package. If the author of a package is unwilling to accept failure reports, I suggest she could leave the Maintainer field blank, or fill it with a dummy value (e.g. "unmaintained"). -k -- If I haven't seen further, it is by standing in the footprints of giants

Max Bolingbroke writes:

...

This is where it stranded the last time, IIRC.  That sentiment makes me a bit uneasy; so you are the official maintainer of a package on Hackage, but you do not want to hear about it when it fails to compile?

Don't forget that some packages fail to compile on Hackage even though they work fine, because e.g. they depend on a third-party C library that is not installed, or depend on some other package that Hackage cannot build.

True, in that case, it's harder to avoid getting one email every time you upload a new version. We should still strive to have stuff build on Hackage (e.g. installing C libs or fixing the ohter packages); if the build fails for one of these reasons, you never know if it fails for other reasons as well. So, I'd *love* to get an email when my packages fail to build, but I will accept that other people have a more sensitive relationship with their inbox. (I assume that the people who raise this objection - Max and Yitzchak - belong in this category? It's not entirely clear from your comments, and I do hope we're not avoiding useful functionality based on a purely *hypothetical* problem.) Conrad suggested creating a mailing list per package, another option could be to automatically post to a single maintainers list, highlighting the package (and preferably also maintainer) name in the Subject. A decent MUA could then up-score the more relevant messages. I'd really like to see Hackage move to a continuous integration type of system, where everything is automatically built and tests are run on every submission. If somebody works out the software infrastructure, I'll volunteer CPU cycles. Next hackathon? -k -- If I haven't seen further, it is by standing in the footprints of giants

On 1 November 2011 10:14, Ketil Malde wrote:

So, I'd *love* to get an email when my packages fail to build, but I will accept that other people have a more sensitive relationship with their inbox.  (I assume that the people who raise this objection - Max and Yitzchak - belong in this category?

Don't get me wrong, I personally would like such a notification service. I'm just making a case for making it somehow opt-out, perhaps at a per-package granularity. I already use the packdeps service to find out when I should relax my package's version bounds. Packdeps delivers this information to me via RSS, which I think this is a great solution - I don't feel under any pressure to read it but the information is there if I want to have a look. So ideally what I would like from Hackage 2.0 is a RSS feed that includes build failure messages, packdeps-like information and perhaps other stuff -- notification of automated testsuite failures, milestones reached ("Your edit-distance package has been downloaded 1000 times! Congratulations!" :-)) and new reviews/comments on my packages (if Hackage ever gets that feature). Max

I wrote:

...

This would be nice. However, there would have to be a way for it to be turned on and off by the author. (Spam is not nice.)

Ketil Malde wrote:

This is where it stranded the last time, IIRC.  That sentiment makes me a bit uneasy; so you are the official maintainer of a package on Hackage, but you do not want to hear about it when it fails to compile?

You are absolutely right about this. In fact, besides build failures, it probably would be a good idea for each maintainer to get, say, one automated email per month with a summary of all the packages that person is officially maintaining, even when there are no build failures. So I'm changing my vote to +1. But let's think about why the instinctive reaction is to be hesitant about this. First of all, an automated system like a build bot can go wrong. What guarantee is there that I won't be flooded with emails when that happens, if I can't shut it off myself? Second, let's say someone decides they don't want to be maintainer anymore. Are they married for life? There is currently no way to remove a package. I guess they would have to upload a new version with no maintainer. I am just a little worried that if uploading to Hackage requires agreeing to unlimited uncontrollable spamming by a bot, it may cause some good packages not to be uploaded by people who are hesitant to agree to that. Thanks, Yitz

On 1 November 2011 21:35, Ketil Malde wrote:

or even

 Maintainer: Ketil Malde <ketil at malde dot org>  -- email me if you are human

Though unless the hackage email bot is smart enough, this will result in a lot of unsendable emails... -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

How about to a new optional Cabal field like "mail-report"? (don't bother about this name, I chose it randomly) If a build failure happens, or there is some relevant information about your package, Hackage will send a mail to the direction specified in that field. A field which content will NOT appear in the package page, so internet bots can't record so easily your mail direction to send you real spam. This is the reason because I write my direction in the "name at domine dot com" form (since a while ago), in spite of I would really like to receive mails about fails in those packages I maintain. Furthermore, since the field would be optional, you still can avoid to receive these mails. -- Daniel Díaz

On Tue, Nov 1, 2011 at 08:24, Nick Bowler wrote:

On 2011-11-01 12:59 +0100, Daniel Díaz Casanueva wrote:

...

How about to a new optional Cabal field like "mail-report"? (don't bother about this name, I chose it randomly)

Doing anything like this in the .cabal file is a mistake, since there is no way to change it after uploading.

If your mail address changes, or if you don't want to maintain a package any more, or if you simply change your mind about receiving status updates by email, then if this gets hardcoded in the .cabal file you have no recourse.

Additionally, if you maintain a lot of packages, you don't really want to have to change it everywhere; this kind of setting is really per maintainer, not necessarily per package. (It is also arguably not of much interest to someone downloading the package. Users' questions and bug reports would generally be expected to go to the main contact address, not the buildbot automated report address.) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Nov 1, 2011 8:45 PM, "Daniel Díaz Casanueva" wrote:

Then, the mailing list seems to be an option. But then I will receive

mails for every package, and there is a lot of packages! Is not a lot of mails this? There is another work around?

Nobody would read every build error for thousands of packages; such a list is useless as-is, and requires any recipient to customize filters to be of any use. Per-package removes the need for filters: just subscribe to the packages you care about. An rss feed would be perfect: it's easy to ignore old reports. Also, implementing rss is just a matter of generating one more "web page" per package: no mailserver or list config required. Conrad.

Ross> A field in the .cabal file is just as available to bots as Ross> a field on the package page. Yes, absolutly. There are at least one easy solution for this problem : having a server-side user model that is related to packages, or to packages versions, indicating wich user is the maintainer of which package. User would be able to provide its mail address, as well as some preferencies. I think it is planned on hackage 2.0 already. A .cabal based solution would need hackage to use asymetric encryption and to provide a public key that maintainer would use to encode its email address. But I'm not sure its worth the trouble. -- Paul

On 2 November 2011 01:08, Diego Souza wrote:

The idea is simple: there are many different platforms that would be to expensive for one to support. So they ask the community for help, and then distribute the load amongst the perl community.

Duncan and co have been working towards something similar for a while in the form of build reports. Cabal can submit a report of whether a build failed/succeeded and can opt to send a full log as well. The new Hackage Server is capable of collecting these reports and taking action based on them. For example, you could setup Hackage server to detect patterns in these build reports such as "80% of builds with GHC 7 are OK, but 100% of builds with GHC 7.2 fail". So far the infrastructure is there for creating and collecting reports. I'm not sure whether reporting is turned on by *default* in Cabal at the moment, which is something we might want to do. One thing that I'm certain of is that there are no analyses that try to find interesting patterns in the reports. If anyone is interested in the issue that might be a good place to contribute and move things forward. Max