W projekcie KDE zbiera się na kolejną zmianę w sposobie rozwijania kodu. Padła już dość konkretna propozycja, aby wyjść z okowów Subversion i wdrożyć jeden z rozproszonych systemów kontroli wersji.
Sam pomysł nie jest nowy, podobna dyskusja miała miejsce już rok temu, a głos (oczywiście na rzecz gita) zabierał między innymi Linus Torvalds. Obecnie git jest opcją rozważaną, ale autorzy propozycji — Sebastian Kügler i Dirk Müller — nie chcą się zamykać także na inne rozwiązania.
Część osób wyraża wątpliwości, czy to aby nie za szybko, skoro pamiętają jeszcze migrację na Subversion sprzed około 3 lat, ale argument liczbowy jest poważny: do wersji 3.5 projekt dochodził przez 8 lat, wprowadzając do repozytorium około 420.000 zmian, a sam skok z 3.5 do 4.0 to aż 300.000 zmian w zaledwie 2 lata, ostatnio repozytorium było więc wykorzystywane przeciętnie 2,5 raza bardziej intensywnie niż wcześniej. Dochodzą też nowe platformy, które dodatkowo komplikują sprawę.
Przy takiej skali zmian — a wszystko wskazuje, że będzie ona nadal rosła — warto pomyśleć jak zdecentralizować rozwój, aby nie dopuścić do blokad w tym procesie. Wybór oprogramowania nie jest oczywiście bez znaczenia, ale najważniejsza jest zmiana ogólnej koncepcji.
W modelu rozproszonym przygotowanie do wydania zaczynałoby się od zgłaszania indywidualnych gałęzi, które powinny zostać uwzględnione w nowej wersji KDE (“Publish Milestone”). Kolejny krok to “Branch Milestone”: zostaje utworzona specjalna gałąź, w której przez następne miesiące można wprowadzać tylko poprawki. W tym czasie “pień” repozytorium jest otwarty dla zmian. “Tested Milestone” to z kolei chwila, gdy zostają podjęte ostateczne decyzje co wchodzi do wydania, a co nie. Gałąź wydania zostaje oczywiście dla wprowadzania dalszych poprawek, ale główny proces rozwoju — wraz z wypracowanymi w tej gałęzi zmianami — wraca do pnia.
Dzięki temu każdy chętny może prowadzić prywatną, dowolnie eksperymentalną gałąź repozytorium, nie czyniąc szkód w głównej gałęzi, a gdy nadchodzi czas “mrożenia” funkcjonalności do wydania, to zainteresowani deweloperzy odchodzą na bok nie wiążąc rąk pozostałym. To bardzo ważne ze społecznościowego punktu widzenia, ponieważ zawsze tylko część osób chce pracować nad szlifowaniem kodu — cała reszta jest bardziej produktywna gdy zajmuje się bardziej twórczymi sprawami.
W nowym modelu można też łatwo zapewnić komfort tym, którzy przyzwyczaili się do obecnego sposobu rozwoju poprzez stworzenie specjalnej gałęzi, która będzie “udawała” dzisiejszy pień repozytorium.
Nad propozycją tej dużej zmiany w ekosystemie KDE trwają dyskusje na liście kde-core-devel (ogólna koncepcja) oraz na kde-scm-interest (wybór konkretnego systemu kontroli wersji).
