[Numpy-discussion] What is consensus anyway

Matthew Brett matthew.brett@gmail....
Tue Apr 24 11:38:08 CDT 2012


Hi,

On Tue, Apr 24, 2012 at 6:14 AM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
>
>
> On Mon, Apr 23, 2012 at 11:35 PM, Fernando Perez <fperez.net@gmail.com>
> wrote:
>>
>> On Mon, Apr 23, 2012 at 8:49 PM, Stéfan van der Walt <stefan@sun.ac.za>
>> wrote:
>> > If you are referring to the traditional concept of a fork, and not to
>> > the type we frequently make on GitHub, then I'm surprised that no one
>> > has objected already.  What would a fork solve? To paraphrase the
>> > regexp saying: after forking, we'll simply have two problems.
>>
>> I concur with you here: github 'forks', yes, as many as possible!
>> Hopefully every one of those will produce one or more PRs :)  But a
>> fork in the sense of a divergent parallel project?  I think that would
>> only be indicative of a complete failure to find a way to make
>> progress here, and I doubt we're anywhere near that state.
>>
>> That forks are *possible* is indeed a valuable and important option in
>> open source software, because it means that a truly dysfunctional
>> original project team/direction can't hold a community hostage
>> forever.  But that doesn't mean that full-blown forks should be
>> considered lightly, as they also carry enormous costs.
>>
>> I see absolutely nothing in the current scenario to even remotely
>> consider that a full-blown fork would be a good idea, and I hope I'm
>> right.  It seems to me we're making progress on problems that led to
>> real difficulties last year, but from multiple parties I see signs
>> that give me reason to be optimistic that the project is getting
>> better, not worse.
>>
>
> We certainly aren't there at the moment, but I can see us heading that way.
> But let's back up a bit. Numpy 1.6.0 came out just about 1 year ago. Since
> then datetime, NA, polynomial work, and various other enhancements have gone
> in along with some 280 bug fixes. The major technical problem blocking a 1.7
> release is getting datetime working reliably on windows. So I think that is
> where the short term effort needs to be. Meanwhile, we are spending effort
> to get out a 1.6.2 just so people can work with a stable version with some
> of the bug fixes, and potentially we will spend more time and effort to pull
> out the NA code. In the future there may be a transition to C++ and
> eventually a break with the current ABI. Or not.
>
> There are at least two motivations that get folks to write code for open
> source projects, scratching an itch and money. Money hasn't been a big part
> of the Numpy picture so far, so that leaves scratching an itch. One of the
> attractions of Numpy is that it is a small project, BSD licensed, and not
> overburdened with governance and process. This makes scratching an itch not
> as difficult as it would be in a large project. If Numpy remains a small
> project but acquires the encumbrances of a big project much of that
> attraction will be lost. Momentum and direction also attracts people, but
> numpy is stalled at the moment as the whole NA thing circles around once
> again.

I think your assumptions are incorrect, although I have seen them before.

No stated process leads to less encumbrance if and only if the
implicit process works.

It clearly doesn't work, precisely because the NA thing is circling
round and round again.

And the governance discussion.

And previously the ABI breakage discussion.

If you are on other mailing lists, I'm sure you are, you'll see that
this does not happen to - say - Cython, or Sympy.   In particular, I
have not seen, on those lists, the current numpy way of simply
blocking or avoiding discussion.   Everything is discussed out to
agreement, or at least until all parties accept the way forward.

At the moment, the only hope I could imagine for the 'no governance is
good governance' method, is that all those who don't agree would just
shut up.   It would be more peaceful, but for the reasons stated by
Nathaniel, I think that would be a very bad outcome.

Best,

Matthew


More information about the NumPy-Discussion mailing list