<div dir="ltr">The only thing a trustee (or maintainer) can revise on an existing version is they can tighten or relax constraints for the cabal file. This can be used when a bound proved in practice to be too liberal or was insufficiently liberal to support the latest version of its dependencies without any semantic changes.<div><br></div><div>Anything more (such as adding an instance for a superclass), fixing an import collision, etc. requires an new version.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 31, 2015 at 10:52 AM, Sumit Sahrawat, Maths & Computing, IIT (BHU) <span dir="ltr"><<a href="mailto:sumit.sahrawat.apm13@iitbhu.ac.in" target="_blank">sumit.sahrawat.apm13@iitbhu.ac.in</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Seems legit. If trustees can only release new versions, then that's the end of the discussion. I thought that trustees had the ability to revise the versions.<div>Sorry for making a fuss.</div><div><br></div><div>Best.</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 31 March 2015 at 20:16, Adam Bergmark <span dir="ltr"><<a href="mailto:adam@bergmark.nl" target="_blank">adam@bergmark.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sumit, It's unclear to me whether you are referring to publishing new revisions of versions or publishing new versions of packages.<div><br></div><div>We have not discussed treating minor source changes as publishing new revisions, my impression has been that we would upload a new version. Maintainers can of course already do this.</div><div><br></div><div>The introduction of metadata (.cabal file) revisions has already caused lots of heated discussion, so I wouldn't dare to suggest hackage serving fetching different tarballs on top of that :)</div><span><div><br></div><div>On Tue, Mar 31, 2015 at 4:25 PM, Sumit Sahrawat, Maths & Computing, IIT (BHU) <span dir="ltr"><<a href="mailto:sumit.sahrawat.apm13@iitbhu.ac.in" target="_blank">sumit.sahrawat.apm13@iitbhu.ac.in</a>></span> wrote:<br></div></span><div class="gmail_extra"><div class="gmail_quote"><span><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"><div dir="ltr">Carter,<div><br></div><div>Yes, I was talking about allowing maintainers to make source level edits.</div><div>I don't see any harm in allowing broken packages to be updated as they won't work for anyone otherwise.</div><div><br></div><div>I am not very inclined towards having the trustees edit packages directly. They themselves didn't do it very much till now, and they shouldn't have to.</div><div>They can instead contact the maintainer and have him fix the issues. In case the maintainer is missing, they have no choice but to go ahead with the changes.</div></div></blockquote><div><br></div></span><div>Yes, maintainers should always be the go-to people for fixes, in a perfect world trustees would not be needed.</div><span><font color="#888888"><div> </div><div>- Adam</div></font></span><div><div><div><br></div><div><br></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"><div dir="ltr"><div><br></div><div>It's a good balance, as having a small group of trustees will ultimately lead to slow response, whereas a large group is not preferable.</div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On 31 March 2015 at 18:15, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<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"><p dir="ltr">Maintainers can already edit the meta data for their own packages.  </p>
<p dir="ltr">As for small source changes, are you proposing that trustees have enough acls to do those by default, or that hackage editing allow source level changes?</p><div><div>
<div class="gmail_quote">On Mar 31, 2015 7:23 AM, "Sumit Sahrawat, Maths & Computing, IIT (BHU)" <<a href="mailto:sumit.sahrawat.apm13@iitbhu.ac.in" target="_blank">sumit.sahrawat.apm13@iitbhu.ac.in</a>> wrote:<br type="attribution"><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"><div dir="ltr">As Roman said, that definitely is a step in the right direction, but as hackage grows, it might not be possible for a small group of trustees to do all the work.<div><br><div>I have some points that might be good to add:<div><ol><li>The maintainers also get the same abilities as the trustees (<span style="font-size:12.8000001907349px">edit .cabal files, edit other package metadata etc.)</span></li><li><span style="font-size:12.8000001907349px">The trustees can then notify the maintainers (if the changes</span><span style="font-size:12.8000001907349px"> are considerable) or make the changes themselves otherwise.</span></li><li><span style="font-size:12.8000001907349px">This also allows the maintainers to edit packages in case they don't build, effectively removing the issue of what a "small source change" is.</span></li></ol></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 31 March 2015 at 16:16, Roman Cheplyaka <span dir="ltr"><<a href="mailto:roma@ro-che.info" target="_blank">roma@ro-che.info</a>></span> wrote:<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">This is still very conservative, but definitely a step in the right<br>
direction.<br>
<div><div><br>
On 31/03/15 13:33, Adam Bergmark wrote:<br>
> Dear Haskell Community,<br>
><br>
> For some time Hackage has contained a user group called "Trustees",<br>
> <a href="http://hackage.haskell.org/packages/trustees/" target="_blank">http://hackage.haskell.org/packages/trustees/</a> .<br>
><br>
><br>
> Description: The role of trustees is to help to curate the whole<br>
> package collection. Trustees have a limited ability to edit package<br>
> information, for the entire package database (as opposed to package<br>
> maintainers who have full control over individual packages). Trustees<br>
> can edit .cabal files, edit other package metadata and upload<br>
> documentation but they cannot upload new package versions."<br>
><br>
> In short, making sure that packages keep building and filling the gap<br>
> between unreachable maintainers and package take-overs.<br>
><br>
> Up until now we have been very careful with changes since we haven't<br>
> had a defined process. Spurred by SPJ and others we have been working<br>
> on a proposal for how we should operate.<br>
><br>
> You can find the proposal here:<br>
> <a href="https://gist.github.com/bergmark/76cafefb300546e9b90e" target="_blank">https://gist.github.com/bergmark/76cafefb300546e9b90e</a><br>
><br>
><br>
> We would now like your feedback!<br>
><br>
> Some specific things from the proposal that we'd like your opinion on:<br>
><br>
> * Section 1: No opt-out for restricting bounds<br>
> * Section 2: Opt-out rather than opt-in procedure for loosening version<br>
> constraints<br>
> * Section 2: Do you care whether you are notified before or after a<br>
> version constraint is loosened?<br>
> * Section 3: The time frame for publishing simple source changes<br>
> * Section 3: What exactly should constitute a "simple source change"<br>
><br>
><br>
> We also have a github repository where YOU can file issues about<br>
> broken packages, you can start doing this right now!<br>
> <a href="https://github.com/haskell-infra/hackage-trustees/" target="_blank">https://github.com/haskell-infra/hackage-trustees/</a><br>
><br>
><br>
> Please share this with as many people as possible.<br>
> We are looking forward to hear your thoughts!<br>
><br>
> Sincerely,<br>
> Adam Bergmark<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>Regards</div><div dir="ltr"><div><br></div><div>Sumit Sahrawat</div></div></div></div></div></div></div>
</div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>Regards</div><div dir="ltr"><div><br></div><div>Sumit Sahrawat</div></div></div></div></div></div></div>
</font></span></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>Regards</div><div dir="ltr"><div><br></div><div>Sumit Sahrawat</div></div></div></div></div></div></div>
</font></span></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>