Proposal: Taking over/up network maintainership

[Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)]

Hello Merijn,

> So, to the best of my knowledge 'network' is currently maintained by
> libraries@/the community, which is code for "not maintained". I've
> previously entertained the thought of taking up maintainership, but so
> far was held back by the fact that I don't do windows dev
> experience. I've discussed this in #ghc before and the consensus was
> that *nix only maintenance is probably still better than no
> maintenance.

As Evan explained, Evan and I are the maintainers. But our activities
are limited to bug fixes, documentation updates and catch-up to new
GHCs.

I welcome you to be a maintainer.

I think we need a guideline for contributions. hs-tls is doing this
very well. See:

	https://github.com/vincenthz/hs-tls/blob/master/CONTRIBUTING.md

The contributors of hs-tls review others' PRs and its history stays
linear. It's really nice.

> My plans are to:
> Short term: fix obvious errors like getContents, cut through the PR
> backlog on github to see what can be merged, what needs work, etc.
> 
> Medium term: Improve exception/error handling (network specific
> exception type that people can catch), better (async) exceptions
> safety guarantees/documentation of safety
> 
> Long term: I would like ditch the current (deprecated) high-level
> interface and replace it with modern high level API.
> 
> Now, the biggest problem is that I don't have experience developing on
> Windows and neither the time nor the motivation to get started with
> that, so I will need someone to take up co-maintainership of the
> windows parts (I'll probably send an email about this to -cafe if
> people are supportive of me taking up maintenance).

Evan and I don't have milestones for new features. If you want to
develop the network library aggressively, please create milestones on
github so that contributors can understand what you are trying to do.

As Evan said, the backward compatibility is important for this
library. And I would support Michael's idea: "deprecate the old
high-level interface, and add a new, better designed high-level
interface".

--Kazu