<div dir="ltr">2013/5/6 Tillmann Rendel <span dir="ltr">&lt;<a href="mailto:rendel@informatik.uni-marburg.de" target="_blank">rendel@informatik.uni-marburg.de</a>&gt;</span><br><div class="gmail_extra"><div class="gmail_quote">


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Petr Pudlák wrote:<div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
    ---------- Forwarded message ----------<br>
    From: *Niklas Hambüchen* &lt;<a href="mailto:mail@nh2.me" target="_blank">mail@nh2.me</a> &lt;mailto:<a href="mailto:mail@nh2.me" target="_blank">mail@nh2.me</a>&gt;&gt;<br>
    Date: 2013/5/4<br>
    ...<br>
    I would even be happy with newhackage sending every package maintainer a<br>
    quarterly question &quot;Would you still call your project X &#39;maintained&#39;?&quot;<br>
    for each package they maintain; Hackage could really give us better<br>
    indications concerning this.<br>
<br>
<br>
This sounds to me like a very good idea. It could be as simple as &quot;If<br>
you consider yourself to be the maintainer of package X please just hit<br>
reply and send.&quot; If Hackage doesn&#39;t get an answer, it&#39;d just would<br>
display some red text like &quot;This package seems to be unmaintained since<br>
D.M.Y.&quot;<br>
</blockquote>
<br></div>
I like the idea of displaying additional info about the status of package development, but I don&#39;t like the idea of annoying hard-working package maintainers with emails about their perfect packages that actually didn&#39;t need any updates since ages ago.<br>


</blockquote><div><br></div><div>I understand, but replying to an email with an empty body or clicking on a link once in a few months doesn&#39;t seem to be an issue for me. And if somebody is very busy and doesn&#39;t update the package, it&#39;s more fair to signal from the start that (s)he doesn&#39;t want to maintain the package.</div>

<div><br class="">Personally it happened to me perhaps several times that I used a promising package and discovered later that&#39;s it&#39;s not being maintained. I&#39;d say that the amount of time required to confirm if authors maintain their packages is negligible compared to the amount of time people lose this way.<br>

</div><div><br></div><div>Just out of curiosity, do you have some examples of such packages, that are being maintained, but not updated since they&#39;re near perfect? I&#39;d like to know if this is a real issue. It seems to me</div>


<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
So what about this: Hackage could try to automatically collect and display information about the development status of packages that allow potential users to *guess* whether the package is maintained or not. Currently, potential users have to collect this information themselves.<br>



<br>
Here are some examples I have in mind:<br>
<br>
 * Fetch the timestamp of the latest commit from the HEAD repo<br>
 * Fetch the number of open issues from the issue tracker<br>
 * Display reverse dependencies on the main hackage page<br>
 * Show the timestamp of the last Hackage upload of the uploader<span><font color="#888888"><br>
<br>
Tillmann<br></font></span></blockquote><div><br></div><div style>Those are good ideas. Some suggestions:</div><div><br></div><div>I think we already have the timestamp of each upload, this already gives some information. Perhaps we could add a very simple feature saying how long ago that was and adding a warning color (like yellow if more than a year and red if more than two years).</div>

<div><br></div><div>Reverse dependencies would certainly help a lot, but it works only for libraries, not for programs. (Although it&#39;s less likely that someone would search hackage for programs.)</div><div><br></div>

<div>The problem with issue trackers is that (a) many packages don&#39;t have one, (b) there are many different issue trackers.</div><div><br></div></div><br></div><div class="gmail_extra" style>Best regards,<br>Petr</div>

</div>