(ccing hackage admin alias directly,
just to make sure the right people are seeing all the emails)
I think there are two _different_ issues we've been conflating
under "taking over a package".
1) A package is genuinely unmaintained and it should be taken over
by someone else, and someone steps up. This is fine to take some
time, in my book. Our current process, as described by Johan
Tibell, is reasonable. It _should_ be easily accessible from the
hackage homepage, _and_ it should be on the haskell wiki. Perhaps
the homepage could link to a hackage FAQ on the wiki? Volunteers
on any of this?
2) A package needs patching to work with the latest deps, and the
maintainer is unreachable, then we just want to upload a fixed
version soon. But who knows, maybe we don't want to take it over
for good. Maybe the maintainer is just on a monthlong vacation on
a small island chain. Maybe they're sick, or busy at work. This is
the sticking point.
So maybe we could have a different policy on the latter. There are
people like Roman, Ben, others, who I feel like I sort of "know"
from their presence in the community, whether or not I've met them
personally. I'd feel comfortable letting trusted community members
not "take over" packages entirely without process, but use a more
relaxed process simply to upload simple patches for compatibility,
etc.
Is there some way that we could create a "two process" approach --
one for taking over a package, and a more relaxed one for trusted
individuals to fix things up easily?
--Gershom
On 1/30/14, 11:53 AM, Ben Gamari wrote:
Clark Gaebel <cgaebel@uwaterloo.ca> writes:
How does the process of taking over maintenance add latency to your work?
1) Check out broken version of package.
2) Fix locally, bump version number locally.
3) cabal sandbox add-source ../fixed-package in any package that needs the
fixed version.
4) Email hackage admins for upload rights.
5) Continue working on your actual project.
6) Receive upload privileges one day.
7) Upload fixed package.
As far as I can tell, the only real latency cost here is that paid to fix
the broken version.
In my experience, step 4 involved several round trips between a number
of different people. Admittedly, this is in part because it's easy to
forget about the broken package after you have fixed it locally.
Cheers,
- Ben
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe