On Apr 26, 2012, at 10:29 PM, Charles R Harris wrote: > > > On Tue, Apr 24, 2012 at 6:46 PM, Travis Oliphant <[email protected]> wrote: > > On Apr 24, 2012, at 6:59 PM, Charles R Harris wrote: > >> >> >> On Tue, Apr 24, 2012 at 5:24 PM, Travis Oliphant <[email protected]> wrote: >> >> On Apr 24, 2012, at 6:01 PM, Stéfan van der Walt wrote: >> >> > On Tue, Apr 24, 2012 at 2:25 PM, Charles R Harris >> > <[email protected]> wrote: >> >>> Why are we having a discussion on NAN's in a thread on consensus? >> >>> This is a strong indicator of the problem we're facing. >> >> >> >> We seem to have a consensus regarding interest in the topic. >> > >> > For the benefit of those of us interested in both discussions, would >> > you kindly start a new thread on the MA topic? >> > >> > In response to Travis's suggestion of writing up a short summary of >> > community principles, as well as Matthew's initial formulation, I >> > agree that this would be helpful in enshrining the values we cherish >> > here, as well as in communicating those values to the next generation >> > of developers. >> > >> >> From observing the community, I would guess that these values include: >> > >> > - That any party with an interest in NumPy is given the opportunity to >> > speak and to be heard on the list. >> > - That discussions that influence the course of the project take place >> > openly, for anyone to observe. >> > - That decisions are made once consensus is reached, i.e., if everyone >> > agrees that they can live with the outcome. >> >> This is well stated. Thank you Stefan. >> >> Some will argue about what "consensus" means or who "everyone" is. But, >> if we are really worrying about that, then we have stopped listening to each >> other which is the number one community value that we should be promoting, >> demonstrating, and living by. >> >> Consensus to me means that anyone who can produce a well-reasoned argument >> and demonstrates by their persistence that they are actually using the code >> and are aware of the issues has veto power on pull requests. At times >> people with commit rights to NumPy might perform a pull request anyway, but >> they should acknowledge at least in the comment (but for major changes --- >> on this list) that they are doing so and provide their reasons. >> >> If I decide later that I think the pull request was made inappropriately in >> the face of objections and the reasons were not justified, then I will >> reserve the right to revert the pull request. I would like core >> developers of NumPy to have the same ability to check me as well. But, if >> there is a disagreement at that level, then I will reserve the right to >> decide. >> >> Basically, what we have in this situation is that the masked arrays were >> added to NumPy master with serious objections to the API. What I'm trying >> to decide right now is can we move forward and satisfy the objections >> without removing the ndarrayobject changes entirely (I do think the concerns >> warrant removal of the changes). The discussion around that is the most >> helpful right now, but should take place on another thread. >> >> >> Travis, if you are playing the BDFL role, then just make the darn decision >> and remove the code so we can get on with life. As it is you go back and >> forth and that does none of us any good, you're a big guy and you're rocking >> the boat. I don't agree with that decision, I'd rather evolve the code we >> have, but I'm willing to compromise with your decision in this matter. I'm >> not willing to compromise with Nathaniel's, nor it seems vice-versa. >> Nathaniel has volunteered to do the work, just ask him to submit a patch. > > I would like to see Nathaniel and Mark work out a document that they can both > agree to and co-author that is presented to this list before doing something > like that. At the very least this should summarize the feature from both > perspectives. > > I have been encouraged by Nathaniel's willingness to contribute code, and I > know Mark is looking for acceptable solutions that are still consistent with > his view of things. These are all positive signs to me. We need to give > this another week or two. I would prefer a solution that evolves the code > as well. But, I also don't want yet another masked array implementation > that gets little use but has real and long-lasting implications on the > ndarray structure. There is both the effect of the growth of the ndarray > structure (most uses should not worry about this at all), but also the growth > of the *concept* of an ndarray --- this is a little more subtle but also has > real downstream implications. > > Some of these implications have been pointed out already by consumers of the > C-API who are unsure about how code that was not built with masks in mind > will respond (I believe it will raise an error if they are using the standard > APIs -- It probably should if it doesn't). Long term, I agree that the > NumPy array should not be so tied to a particular *implementation* as it is > now. I also don't think it should be tied so deeply to ABI compatibility. > I think that was a mistake to be so devoted to this concept that we created > a lot of work for ourselves --- work that is easily eliminated by > distributions that re-compile down-stream dependencies after an ABI breaking > release of NumPy. I realize, I didn't disagree very strongly before -- I > disagree with my earlier view. That's not to say future releases of NumPy > 1.X will break ABI compatibility --- I just think the price is not worth the > value of the thing we have set as the standard (it's just a simple re-compile > of downstream dependencies). > > We are quite delayed to get things out as you have noted. If the desire is > to get a long-term release schedule for Debian and/or Ubuntu, then I think > the 1.6.2 release is a good idea. It also makes more sense to me as a > Long-Term Release candidate. > > > Now that I've been working on it, I can assure you that 1.6.2 is a terrible > candidate for a long term release. The changes between 1.6 and 1.7 are > already enormous and I'm not even going to try to backport some of the fixes. > In addition, the *big* changes to datetime that made it workable are not in > 1.6. The reason the difference is so big is not only the big delay in the > release schedule, but the fact that 1.7 was being prepared for the takeoff to > 2.0. I think 1.7 or later is the only reasonable candidate for the LTS. >
Thanks for that analysis. That is very helpful to know. -Travis > Chuck > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
