Hi Patrick, I'm sorry you feel like it was railroaded. This has been a long and lengthy discussion and I think we made several improvements on the original proposal, but I also think the vote has passed and it is time to move on, especially in light of the Bernd's and the Board's notion that there is one project with one set of committers. This will take some time to get there.
Some more thoughts inline. On Mar 13, 2010, at 10:36 PM, patrick o'leary wrote: > > If you want a concrete example take Field Collapsing > https://issues.apache.org/jira/browse/SOLR-236 > > That's been around 3 years now, has 61 votes and 72 watchers, yet it's been > sat on... the community has delivered, but committers have refused to heed > them... > It's it complete? As can be seen by the large number of iterations on it, it doesn't appear that those who are working on it think it is complete, either. However, they have done exactly what was asked of them, by breaking it down into smaller issues and working to get those committed (and they are in fact being committed if you look at the subissues). Very large, monolithic patches are very hard to commit. At the rate it is going, it will be in 1.5, but also keep in mind, Field Collapsing is a VERY hard problem, as every committer and who contributor who has worked on it will tell you. > I feel it's more complete that all the function query work that was > committed to Solr trunk for spatial solr... Possibly, but the function query stuff (I presume you are referring to the sort by function error for a very small subset of queries) is _WAY_ smaller and only effects a few files. Field collapsing touches the very deep innards of Solr and touches a lot of Solr. There's a big difference. But, also, if you don't like it, please offer help. I'm not perfect, never have been. Nor is any other committer. That's why it takes a whole community to get it right. I look forward to working with you more on it, as you are much more of an expert on it than I am. I'm confident that if we work together on it, we can crank out a very high quality solution that is better than either you or I could do by ourselves. > It's clearly shown there's two sets of rules for this, as a committer you > can do as you please, as a community member you've got to hope that there is > a committer who needs what you've done or asked for, and agrees with the way > you've implemented it.. For better or worse, this is how every last open source project on the entire planet works, but see below for some more thoughts on this as there is always room for improvement. At least in the ASF, there is a mechanism for the community to become a committer. In most Open Source projects, it is simply the Dictator for Life model and you have zero chance of ever significantly contributing. However, if the community doesn't trust the committers to have the best interest of the project in mind, then the community can either: 1. Abandon the project 2. Step up and pitch in and help out. The ASF has a very clear path to becoming a committer. You have gone down that path. I certainly hope people choose #2, but I can't make them, either. > > That's where I feel there is a lack of diversity in concepts, direction and > design within solr. So, please contribute. You know how the process works. > > And as such I would hate to see the same thing happen to lucene. > > Granted we all work for a living, we can't always work on projects or ideas > others bring to the table. I write code maybe once a month these days, and > often can't keep up with the requests that come into the open source stuff I > support. But I've always allowed others to contribute and extend, if it > compiles, works, and doesn't mess things up, I always feel that if it's > important enough, then iteration will make it better if it needs to be > better. And I've been lucky that several folks on the locallucene world have > rolled up their selves and helped out. Yes, but it also needs to be up to a certain standard as well. There was a lot of feedback, for instance, on SOLR-773 from at least 3 or 4 different committers who suggested ways to make it better fit into Solr's model before committing. I don't understand why iteration before committing is any different from iteration after committing, except that by doing it before you break a lot fewer people and end up with more people happy in the long run. > > I respect, and appreciate folks for taking any hemorrhage of concepts and > making them better, and that's how see open source working. > Likewise, we respect people making contributions. This has always been the case and always will be, as it's the ASF way. > Apache provides hosting, and legal protection for people who develop > community driven projects, but not projects that are restricted to the ideas > of those that have commit karma. This is always a fine line to walk. As a committer, your responsibility is to make sure the code going in meets the quality demands of the project as well as the legal requirements of the ASF. This is further complicated by a large variety of contributors from all over the world with a variety of programming and documentation skills. It is then further complicated by time pressure on all people involved. Finally, being a committer is often as much about knowing what not to touch as what to touch. For instance, on Field Collapsing, I don't feel particularly qualified to work on it. If I did work on it, I know it would take a lot of my time just to get up to speed, and I simply don't have that kind of time, either, which is why I asked the contributors to try to break it up into smaller pieces. This is why I work on the spatial stuff, because I can bite off very small chunks. I wish I could dedicate all my time to it, but I have a day job too. I think if you take a step back from the immediate issue, it's pretty safe to say that those who have been working on Lucene and Solr for the past X years have done a pretty decent job at it. By no means are we perfect, but I think the community as a whole has done a very good job of working through issues and constantly improving the projects. Even as contentious as this issue has been, it has been a very healthy discussion. It is a tremendous tribute to the community as a whole that it has stuck on topic and been on the issues. I've been involved in plenty of other projects where a discussion of this length would have already degenerated into personal attacks. Cheers, Grant
