[zeromq-dev] Proposal for libzmq maintenance

[Pieter Hintjens]

On Mon, Jan 9, 2012 at 10:08 PM, Martin Lucina <martin at lucina.net> wrote:

> This is great. +1 for coming back to the single-repository model.

Well, we kind of cheat by asking all experimental work to happen
outside, but that matches peoples' expectations as far as we can tell.
There are still multiple repositories but libzmq becomes a focal
point.

> So the official zeromq/libzmq repository master branch essentially
> becomes a staging tree for "proposed updates to the next release",
> a.k.a. linux-next, "pu" or similar approaches used by other projects,
> right?

Yes, that's the idea.

> The above, along with the "no direct changes to libzmq" means that
> libzmq/master should only see merge commits of pull requests. Right?

Indeed. With exception of NEWS, as you note below. This is how we've
done the distribution repos with minimum pain and error over the last
year and a half. So it's a proven strategy. It's especially useful IME
that maintainers don't have a stake in specific commits. That prevents
conflicts of interest ("I need this change so I'll bypass agreed
procedure") which we all fall foul of.

> It would be good to see "pull request" explicity defined as "an e-mail
> sent to the zeromq-dev mailing list by the repository owner, asking the
> maintainers to pull from git://.../some-branch".

Automatically. There's no benefit in forcing this to be manual, and
there are risks. People can also subscribe separately to pull request
emails.

> Further, pull requests created on Github but *not* also sent to the
> mailing list must be ignored by the maintainers, and this would be
> prominently documented.

Having used pull requests for some time now, my preference is to have
them announced and discussed unavoidably, and then deleted if they
don't come up to scratch. Otherwise you get an accumulation of old
pull requests. A pull request becomes stale rapidly, it has to be
accepted or deleted within a few days depending on the rate of change.

> Rationale: This is needed to keep the process of accepting new changes
> into master transparent to all interested parties (maintainers,
> developers, users, lurkers, ...) and to avoid fragmenting the discussion
> or code review.

Indeed. We'll hook up github to email the list automatically. IMO the
same should eventually happen for new issues (not comments on issues).

> This doesn't stop anyone from using Github or other Web 3.0 coolness to
> create pull requests, but it does ensure that everyone else is kept in
> the loop on any discussion while not being forced to use the same Web
> 3.0 coolness.

Personally, after trying all the options, I'm unwilling to apply
patches by any other means except pull requests and quite willing to
argue this one. The advantages so far outweigh the philosophical
objections.

Thanks for the comments. I think we're finding clear water here.

-Pieter