Stało się – po dyskusji rozpoczętej przez Dawida Weiss oraz głosowaniu nad tym, aby Solr został Top Level Project fundacji Apache wszystko jest jasne – od teraz drogi Lucene i Solr będą się powoli rozchodzić. Przynajmniej jeżeli chodzi o repozytorium kodu, czy nowe publikację nowych wersji. W związku z tym nadszedł czas, aby przyjrzeć co to oznacza dla nas, użytkowników i oczywiście dla solr.pl 🙂
Jak wyglądało głosowanie?
Niektórzy czytelnicy mogą być zainteresowani, jak przebiegało głosowanie. Podsumowując zatem – oddano 48 głosów – zarówno commiterzy, członkowie PMC (Project Management Commitee) oraz członkowie społeczności. Warto wspomnieć, iż tylko głosy członków PMC były wiążące. 40 osób głosowało za podziałem, 8 osób głosowało przeciw. Spośród tych głosów 33 głosy za były wiążące, przeciw tylko 4 głosy były wiążące. Jak widać przewaga głosów za podziałem była całkiem znacząca.
Co to tak naprawdę oznacza?
Zaczynając od teraz możemy spodziewać się powolnego rozdzielania projektów. Zakończone głosowanie oznacza, iż Solr oraz Lucene będą się powoli rozdzielać i rozwijać się we własnym tempie. Oczywiście, nie oznacza to, iż Solr przestanie korzystać z Lucene jako biblioteki wyszukiwania pełnotekstowego. Aczkolwiek istnieje możliwość, iż na zmiany wprowadzone do biblioteki Lucene Solr będzie musiał poczekać dłużej.
Osobom zainteresowanym co będzie się działo dalej polecam dwa miejsca. Po pierwsze SOLR-14497, czyli rzeczy, które należy wykonać, aby Solr stał się pełnoprawnym projektem wysokiego poziomu. Oczywiście nie oznacza to tylko przeniesienia kodu do oddzielnego repozytorium i stworzenia strony WWW projektu. Konieczne jest wybranie PMC, konieczne jest wybranie commiterów z pośród wszystkich ludzi posiadających w tej chwili prawo do modyfikacji repozytorium kodu. Konieczne jest zdecydowanie co zrobić z archiwum list dyskusyjnych, środowiskami integracyjnymi, czy serwerami na których budowany jest kod. Jak widać proces rozdzielenia projektów nie jest banalny, wymaga sporo pracy i minie trochę czasu zanim wszystko zostanie sfinalizowane. Po zakończeniu tego procesu konieczne będzie posprzątanie rzeczy związanych z biblioteką Lucene i właśnie tego dotyczy zgłoszenie LUCENE-9375.
Przyszłość obu projektów
Zacznijmy od prostego pytania – co rozdzielenie oznacza dla obu projektów? Na pewno mniejsze skomplikowanie. Każdy z projektów będzie miał własny kod źródłowy, mniejszy w porównaniu do tego co mamy teraz. Każdy z projektów będzie miał własne testy, a nowe funkcjonalności będą mogły być dodawane bez oglądania się na drugi z projektów. Solr nie będzie blokować zmian w Lucene, a programista zmieniając Lucene nie będzie zmuszony do wprowadzania zmian po stronie Solr. Niektórzy znają Lucene, ale nie są dobrze zaznajomieni z kodem Solr. Oczywiście mniej kodu oznacza także mniejsze testy, a co za tym idzie szybciej wykonujące się testy. To powinno przyspieszyć prace programistyczne i wyjść na dobre obu projektom.
Chciałbym jednak podkreślić, w sumie to powinienem napisać to na początku – Lucene i Solr już od dość długiego czasu są tak naprawdę rozwijane oddzielnie. Oba projekty mają wspólne repozytorium kodu, ale jednak korzystają z dwóch oddzielnych katalogów. Oczywiście zmiany w bibliotece Lucene mogły wymuszać zmiany po stronie Solr, ale to ma swoje plusy i minusy. Jeżeli chodzi o inne rzeczy – listy dyskusyjne są oddzielne już od dawna, nowe wersje są oddzielne jeżeli chodzi o binaria, aczkolwiek numerowane tak samo. Zgłoszenia w JIRA są także oddzielne. Co więcej, bardzo dużo nowych zmian przygotowywanych jest w taki sposób, aby tworzyć oddzielne patche do Lucene i Solr.
Przyszłość Lucene
Moim zdaniem Lucene zyska na podziale projektów. Po pierwsze koniec z oglądaniem się na Solr jeżeli chodzi o zmiany. Są funkcjonalności, takie jak stare, numeryczne typy danych. Lucene usunęło te typy, podczas gdy Solr dalej je wspiera. Wymaga to pewnej gimnastyki od programisty, której będzie można teraz uniknąć. Ten przykład podniesiony został podczas dyskusji poprzedzającej głosowanie nad rozłączeniem projetków.
Mniejszy, mniej ściśle połączony kod oznacza szybszy i łatwiejszy rozwój oraz większą elastyczność. Mniejszy kod źródłowy to mniej testów i potencjalnych błędów co może także skutkować szybszym rozwojem. Brak konieczności martwienia się o zmiany w Solr to także plus i przyspieszenie, przynajmniej z punktu widzenia Lucene.
Przyszłość Solr
Wiem, świat nie jest czarno-biały i jest dużo innych kolorów. Jako użytkownicy Solr możemy martwić się, iż ten bardzo dobry silnik wyszukiwania będzie w tyle za zmianami w bibliotece Lucene. Oczywiście możemy się o to martwić, ale to mogłoby wydarzyć się i przed podziałem – zamiast aktualizować Solr mogliby przesuwać rzeczy. Zamiast tego widać, że ludziom odpowiedzialnym za oba projekty po prostu zależy i nie powinno się to zmienić tylko dlatego, iż Lucene i Solr nie będą dzielić tego samego repozytorium kodu. Na pewno Solr dostanie mniej uwagi od ludzi, którzy skupieni są tylko i wyłącznie na Lucene, ale to nie jest koniecznie złe. Na pytanie, czy ludzie chcący dokonać zmian w Lucene powinni myśleć o Solr jak o integralnej części tej biblioteki – moim zdaniem nie. Lucene to w końcu biblioteka odpowiedzialna za wyszukiwanie pełnotekstowe, a Solr jest jednym z silników wyszukiwania który z niej korzysta.
Czy Solr będzie w stanie utrzymać tempo zmian, takie jak teraz? Wydaje mi się, że odpowiedź na to pytanie to tak. Solr może korzystać z wersji SNAPSHOT Lucene i być gotowym jak tylko najnowsza wersje biblioteki zostanie opublikowana. Wszystko zależy jak programiści podejdą do integracji. Wydaje mi się nawet, iż korzystanie z wersji SNAPSHOT spowoduje mniej zmian, jakie konieczne będą do wykonania po stronie Solr. W końcu zmiany będą wykonywane na mniej dynamicznym kodzie – to od Solr będzie zależało kiedy zmienić wersję biblioteki, ile czasu poświęcić na polerowanie funkcjonalności, czy kiedy daną funkcjonalność dodać do Solr. Oczywiście, nie zawsze będzie to możliwe, ale w dużej liczbie przypadków będzie. Mam nadzieję, że spowoduje to, iż integracja niektórych elementów i funkcjonalności będzie może wolniejsza, ale za to bardziej dopracowana i tym samym lepsza dla nas, użytkowników.
Przyszłość Solr.pl
Jeżeli chodzi o nas, nie zmieni się dużo. Dalej będziemy Was informować o nowych wydaniach Solr oraz pisać tutoriale i poradniki, jak wykorzystać pewne elementy Solr w Waszych projektach. Dodatkowo, będziemy pisać o nowych wersjach biblioteki Lucene, co pozwoli Wam śledzić w jakim kierunku podąży Solr w najbliższej przyszłości. Mamy nadzieję, że wszystko zostanie po staremu i dalej będziemy mieli o czym pisać 🙂
Podsumowanie
Staram się patrzeć na zmiany pozytywnie i nie doszukiwać się pesymistycznych scenariuszy. Mniejszy kod, lżej powiązany kod, szybsze testy – czyli to co my, programiści lubimy najbardziej. Przynajmniej większość z nas. Z punktu widzenia użytkownika powinniśmy wspierać oba projekty – zarówno Solr, jak i Lucene. W naszym interesie jest to, aby oba były żywe, miały aktywną grupę osób pracujących nad nimi i jak największą społeczność za nimi stojącą. Mam nadzieję, że jakiś czas po publikacji tego wpisu będziemy mogli powiedzieć: „Tak, zmiany poszły w dobrą stronę!”. Ja ze swojej strony zaciskam kciuki za powodzenie zmian, nawet jeżeli są pytania, na które w tym momencie nie mamy odpowiedzi.