As far as I understand the policy-making process, someone from PMC has to start the vote, and then PMC members should, well, vote. Without them taking action we can "beep" to our hearts' content without any consequences.
On Sat, May 30, 2009 at 07:22, Shai Erera <ser...@gmail.com> wrote: > So ... I've this happen a lot of times (especially in my thesis work) - > someone raises a controversial topic, or one that touches the nervous of the > system, there's a flurry of activity and then it dies unexpectedly, even > though it feels to everyone that there's "an extra mile" that should be > taken in order to bring it to completion. > > And that's what I've seen in this thread. A lot has been said - lots of > comments, ideas, opinions. Lots of ranting and complaining. Then it died ... > Thank you Grant for that last "beep", I hope that was an intention to > resurrect it. > > So I ask - how come that we don't have a decision? Is it because we're > "afraid" to make a decision? (that last sentence is supposed to "tease" the > community, not to pass judgement) > > I'm asking because it seems like everybody pretty much agrees on most of the > suggestions, so why not decide "let's do X, Y and Z" and change the > back-compat page starting from 2.9? If people don't remember the decisions, > I don't mind reiterating them. > > (I also ask because I'd like to take the improvements from LUCENE-1614 to > TermDocs/Positions, PhrasePositions, Spans. All except PhrasePositions are > public interfaces and so it matters if I need to go through creating > abstract classes, with new names, or I can change those interfaces, asking > those that implemented their own TermDocs to modify the code). > > Shai > > On Wed, May 27, 2009 at 10:36 PM, Grant Ingersoll <gsing...@apache.org> > wrote: >> >> So, here's a real, concrete example of the need for case by case back >> compat. See https://issues.apache.org/jira/browse/LUCENE-1662 >> >> It's completely stupid that ExtendedFieldCache even exists. It is a dumb >> workaround for a made up problem that has nothing to do with real coders >> living in the modern age of development where IDE's make refactoring these >> types of things very cheap. Namely, the notion that interfaces must never >> change lest every 6-9 months some minute number of users (I'd venture it's >> less than 1% of users) out there, who by any account are completely capable >> of implementing hard core Lucene internals (like extending FieldCache), yet >> are seemingly incapable of reading a CHANGES file with a huge disclaimer in >> it, have to recompile (GASP!) their code and put in a dummy implementation >> of some new interface method. Yet, here we are with Yonik fixing very real >> problems that are a direct result of coding around back compat. (along with >> a mistake; it took a long time for this issue to even be discovered) that >> very much effect the usability of Lucene and the day to day experience of a >> good number of users. >> >> In other words, the real fix for L-1662 is for ExtFieldCache to be folded >> into FieldCache and for the file to be removed, never to be heard from >> again. >> >> The same can be said for the whole Fieldable issue, but that's a different >> day. >> >> Ranting, >> Grant >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> > > -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
