patchowanie mozilli

[Konrad]

v!tam

Zastanawiam się dlaczego Mozilla nie ma możliwości patchowania. Gdy pojawi się jakiś security bug jedyne rozwiązanie to ściągnięcie nowszego nightly builda. Chyba wszyscy się zgodzą, że zdecydowanie lepiej jest dociągnąć łatki.

Czy była już gdzieś na ten temat poruszona dyskysja? Co z niej wynikło?

[Gandalf]

Hmmm... mysle ze wymagaloby to ogromnych zmian, i wiele wiele miesiecy pracy.
Trzeb by przygotowac manager, kontrole tego, jakies orkeslenia bezpieczenstwa itp... mnostwo roboty.

A pamietaj, ze Mozilla trunk builds to tylko dla developerow!!! Nie mowiac juz o tym, ze wogule cale SeaMonkey nie zostalo stworzone dla userow... dla nich jest NS7, Galeon, powstaje Pheonix...

[Konrad]

Hmmm... mysle ze wymagaloby to ogromnych zmian, i wiele wiele miesiecy pracy.
Trzeb by przygotowac manager, kontrole tego, jakies orkeslenia bezpieczenstwa itp... mnostwo roboty.

Bez ogromnych zmian Mozilla utknie. Sam niedowano Jarkowi Piorkowskiemu na p.c.w tlumaczyles ze mozilla jest 'chop do przodu'. Niestety i ona stanie w miejscu jesli nie poslucha userow. Patche i odchudzenie - tego Mozilli brakuje do doskonalosci i zawsze bedzie wyciagane przez konkurencje

A pamietaj, ze Mozilla trunk builds to tylko dla developerow!!! Nie mowiac juz o tym, ze wogule cale SeaMonkey nie zostalo stworzone dla userow... dla nich jest NS7, Galeon, powstaje Pheonix...

Nie zgadzam sie z tym. Jezeli jest tak jak mowisz - mozilla sie zagrzebie. Sorry, ale takie tlumaczenie to omijanie problemow. Jakos ostatnio czesto slysze wlasnie to co piszesz takze i od innych developerow. Sam pisales jak fajnym jest wyjsciem ruch opensource. A ja ostatnio patrze na to coraz bardziej sceptycznie. Raz, ze odpowiedz na prosbe klienta to 'nie jestesmy dla Ciebie tylko dla developerow (bierz nafaszerowany reklamami NN)', dwa to co sie pojawilo w dyskucji nad bugiem na temat braku filtrow na usenet. Mianowicie ktos na to odpowiedzial 'sam sobie napisz na to late'. No sorry...

[GabrielBaines]

Nie wydaje mi się, aby patchowanie Mozilli było duzym problemem.

Standartowe patche tzn. na poziomie kodu źródłowego, byłyby bardzo proste do realizacji. W końcu juz teraz uaktualnienie kodu do HEAD z CVS i przekompiloanie robi sie jednym poleceniem.

Natomiast uaktualnienia na poziomie kodu binarnego wymagałyby rzeczywiście nieco pracy w samej mozilli, no ale bez przesady - podstwawowa infrastruktura juz jest, w końcu jest format XPI i kod który wykorzystywany jest np. w installerze. Gdyby podzielić Mozille na więcej komponentów i udostępniac każdy jako XPI, to uaktualnienie polegałoby na dociągnięciu XPI z uaktualnionymi komponentami. A z samym podziałem na komponenty tez nie byłby duży problem, bo juz teraz ogromna część kodu jest zrobiona jako komponenty XPCOM.

Oczywiście w przypadku uaktualnienia, które zmieniałoby interfejsy wystawiane przez komponenty konieczny byłby mechanizm zależności. Ale na początek mozna załozyc, że zmiana interfejsów wymagałaby juz pociągniecia całej Mozilli, co o tyle byłoby OK, że interfejsy zmieniają się już bardzo rzadko.

[Konrad]

No dobra, ale pozostaje pytanie dlaczego tego jeszcze nie wprowadzono? Ja to sobie tlumacze troche tym, ze koderzy lubia jak im sie na bugzilli przedstawia nr buildu. Przy patchowaniu trudniej bedzie stwierdzic co konkretnie jest w tej Mozilli. ale tez sie da

[Olhado/256]

Przede wszystkim - niewiele jest w Mozilli do patchowania. Security problem pamiętam tylko jeden, ale naprawienie go to kwestia dopisania jednej linijki do user.js (chyba, nie pamiętam... ), więc do tego patch nie potrzebny. Stabilne wydania (1.1, 1.2) są na tyle stabilne właśnie, że można sobie spokojnie czekać do następnej stabilnej wersji i nie trzeba nic patchować.