Yes -- being maintained, and have a lot of commit activity are not the same thing. There are many simple libraries which do not require much ongoing develop. They are designed to do something of limited scope, and they only need to be updated when something breaks. I have thought that a more interesting metric might be to send the maintainer an email when their package stops building automatically on hackage. Then assign some weight based on whether or not they fix things, and how often. - jeremy On Sun, May 5, 2013 at 10:34 PM, Niklas Hambüchen wrote:

I don't think that activity in the repo has too much to do with something being maintained.

Maintainance is a thing humans commit to, so the question of whether something is maintained should be a question to a human.

I often push a quick build failure fix for my packages, some of which I would still in not want to call "maintained".

On Mon 06 May 2013 10:57:49 SGT, Clark Gaebel wrote:

...

If there's a github link in the package url, it could check the last update to the default branch. If it's more than 6 months ago, an email to the maintainer of "is this package maintained?" can be sent. If there's no reply in 3 months, the package is marked as unmaintained. If the email is ever responded to or a new version is uploaded, the package can be un-marked. - Clark On Sunday, May 5, 2013, Lyndon Maydwell wrote:

I've got it!

The answer was staring us in the face all along... We can just introduce backwards-compatibility breaking changes into GHC-head and see if the project fails to compile for x-time! That way we're SURE it's unmaintained.

I'll stop sending emails now.

On Mon, May 6, 2013 at 10:44 AM, Clark Gaebel wrote:

If there's a github link in the package url, it could check the last update to the default branch. If it's more than 6 months ago, an email to the maintainer of "is this package maintained?" can be sent. If there's no reply in 3 months, the package is marked as unmaintained. If the email is ever responded to or a new version is uploaded, the package can be un-marked.

- Clark

On Sunday, May 5, 2013, Lyndon Maydwell wrote:

But what if the package is already perfect?

Jokes aside, I think that activity alone wouldn't be a good indicator.

On Mon, May 6, 2013 at 9:59 AM, Conrad Parker wrote:

On 6 May 2013 09:42, Felipe Almeida Lessa wrote: > Just checking the repo wouldn't work. It may still have some activity > but not be maintained and vice-versa.

ok, how about this: if the maintainer feels that their repo and maintenance activities are non-injective they can additionally provide an http-accessible URL for the maintenance activity. Hackage can then do an HTTP HEAD request on that URL and use the Last-Modified response header as an indication of the last time of maintenance activity. I'm being a bit tongue-in-cheek, but actually this would allow you to point hackage to a blog as evidence of maintenance activity.

I like the idea of just pinging the code repo.

Conrad.

> On Sun, May 5, 2013 at 2:19 PM, Doug Burke wrote: >> >> On May 5, 2013 7:25 AM, "Petr Pudlák" wrote: >>> >>> Hi, >>> >>> on another thread there was a suggestion which perhaps went unnoticed by >>> most: >>> >>>> ---------- Forwarded message ---------- >>>> From: Niklas Hambüchen >>>> Date: 2013/5/4 >>>> ... >>>> I would even be happy with newhackage sending every package maintainer a >>>> quarterly question "Would you still call your project X 'maintained'?" >>>> for each package they maintain; Hackage could really give us better >>>> indications concerning this. >>> >>> >>> This sounds to me like a very good idea. It could be as simple as "If you >>> consider yourself to be the maintainer of package X please just hit reply >>> and send." If Hackage doesn't get an answer, it'd just would display some >>> red text like "This package seems to be unmaintained since D.M.Y." >>> >>> Best regards, >>> Petr >>> >> >> For those packages that give a repository, a query could be done >> automatically to see when it was last updated. It's not the same thing as >> 'being maintained', but is less annoying for those people with many packages >> on hackage. >> >> Doug >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > Felipe. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 7 May 2013 17:36, Ilya Portnov wrote:

Hi Cafe.

...

I have thought that a more interesting metric might be to send the maintainer an email when their package stops building automatically on hackage.

I think, this is "must have" feature for new hackage. If error was occured during build, send email to maintainer:

Except that there are various reasons a package won't build on Hackage: * Temporary glitch with another Haskell dependency (e.g. package Foo depends upon Bar-x.*; maintainer of Bar uploads a new point release of Bar that fails to build just before Foo's maintainer uploads the new version, thus the build server picks the buggy version of Bar and thus the new version of Foo fails to build). * Requires a foreign library that isn't installed on the Hackage build server. * OS-dependent. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

07.05.2013 14:21, Ivan Lazar Miljenovic пишет:

On 7 May 2013 17:36, Ilya Portnov wrote:

...

Hi Cafe.

...

I have thought that a more interesting metric might be to send the maintainer an email when their package stops building automatically on hackage.

I think, this is "must have" feature for new hackage. If error was occured during build, send email to maintainer:

Except that there are various reasons a package won't build on Hackage:

* Temporary glitch with another Haskell dependency (e.g. package Foo depends upon Bar-x.*; maintainer of Bar uploads a new point release of Bar that fails to build just before Foo's maintainer uploads the new version, thus the build server picks the buggy version of Bar and thus the new version of Foo fails to build).

* Requires a foreign library that isn't installed on the Hackage build server.

* OS-dependent.

Anyway, if package does not build, only maintainer can know why and what to do with it. As for OS- and environment-dependent packages, it would be nice to let maintainer mark package as "not buildable", so that hackage should not try to build it. WBR, Ilya Portnov.