On 2017-04-12, Gilles wrote: > [Reminder: a big part of "Commons RNG" was developed inside CM and > most PMC people did not even know about it (although I was opening > JIRA issues all along. Hence creating a "git" repository is not > futile if it can raise awareness.]
By now you've probably learned that people won't look at JIRA issues raised for components they don't work on. At least I don't :-) > On Wed, 12 Apr 2017 15:22:23 +0200, Stefan Bodewig wrote: >> On 2017-04-12, Gilles wrote: >>> IMO, there is a contradiction in the PMC being both passive (not >>> contributing to the overall health of CM[2]) and active (in >>> preventing "do-ocracy" wrt the choice of a roadmap for CM[3]). >> You can count myself into the camp of people who are willing to let a >> component go dormant if it doesn't get maintained. But I'm unlikely >> to go actively looking for unmaintained components. > a _lot_ of work has been done (since at least 4 years) on the branch > that was bound to become CM 4.0. I'm inclined to think that it > deserves more than being thrown away. I'm not suggesting to throw away anything. All I said was that I'm prepared to move unmaintained components to dormant where anybody can pick them up again later. You're saying MATH isn't unmaintained, that's fine. I'm still not sure where you see do-ocracy being prevented. If anybody wanted to RM a MATH release, they can do so. And to me it looks as if nobody was preventing you - or anybody else - from creating new components seeded by code taken from MATH (as long as the number doesn't get scary, I hear you, Oliver :-). It seems creating a git repository as the first step may not be the preferred approach, though. >> I'm not sure we need a roadmap. IMHO if you can identify a viable >> subset of MATH you want to maintain as a separate component, then you >> should be able to do just that. At the same time this shouldn't >> prevent anybody else from working on MATH if they really want to. > Exactly (although the latter did not happen, and it's something for > the PMC to take into account when alternative are proposed). It is probably a lot easier to accept "let's create a new component that focusses on X with code seeded from MATH" than "here is a big plan for how we want to deal with breaking up MATH". I prefer the "small steps" approach taken with RNG and NUMBERS. > As you know, this CM issue has created a lot of grievance. > I do complain that the PMC did not fulfill its role, by not even > trying to safe-guard the "Commons" project's integrity. > I expect the "Commons" PMC to _support_ the people who work here > (cf. "git log"). I read you expect the PMC to do something, but unfortunately I don't understand what it is that you want the PMC to do. Maybe we are are interpreting the role of the PMC differently. In what way has the integrity of the Commons project been endangered? I've seen people fork the code of MATH - which is fine by our license - and move to work in a different environment - which is their choice and I'm not willing to judge them. But the code is still here and anybody is free to keep working on it. No danger for the Commons project IMHO, maybe a danger for the MATH component going dormant which is something that may happen to any other component as well when people stop working on them. I've seen you sticking around to work on MATH and keeping the parts alive that you care deeply about and finding new contributors that share those goal - which is great. The PMC has not been standing in the way of RNG or NUMBERS, maybe discussions have been taking longer than you'd have wanted. But that's what you get inside a chatty community (I'm deliberatly rate-limiting my responses :-). The new contributors have been made committers by the PMC. I'm confident the PMC won't stand in the way of creating new self-contained components in the future, some members of the PMC may quibble over the details, though, and you'll need even more discussions. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
