Gnome 2.2.x

[Tomasz Kłoczko]

On Thu, 27 Mar 2003, Andrzej Krzysztofowicz wrote:

> > 
> > Dnia 2003.03.27 15:33, Tomasz Kłoczko napisał(a):
> > > Prosiłbym raczje o coś innego żeby 2.3 wrzucać do DEVEL, a 2.2 żeby
> > > był na
> > > HEAD.
> > 
> > Dlaczego? Rozwój GNOME idzie pełną parą, do serii 2.2.x wyjdzie 
> > najprawdopodobniej tylko 2.2.2 i wszyscy zapomną o tym, więc niech 
> > sobie spokojnie w branchu siedzi. Mnie jest łatwiej robić aktualizcje i 
> > trzymac to wszystko właśnie w taki sposób jak teraz.
> 
> A czy to, co jest w tej chwili na head dziala ?
> Bo to powinno byc kryterium. Jesli bylo cos, co dzizlalo, to nie powiino
> przestac dzialac po aktualizacji do nowszej wersji.

Chodzi o to, że buildery Ac jak dobrze pójdzie ruszą dzisiaj albo jutro.
Troche jeszcze zejdzie zanim całsoć się rozkręci ale warto juz myśleć o 
tym żeby ograniczyć zuże aksperymenty na HEAD.

Zresztą co do eksperymetów i to włanie takcih dużych to taka metodologia
że najpierw rzyuca sie to na brancha (DEVEL) a po wstępnym dopracowaniu 
robi się merg powinna być uzywana niezaleńie od etapu rozwoju zasobów.
Powinno to dotyczyć czy to skomplikowanych gryp pakeitów tak jak to ma 
miejsce pzry przechdozenei na kolejne wersje GNOME czy KDE ale takze 
pojedynczych pakietów o wysokiej komplikacji jak XFree86 czy kernel.
Bardzo dobrze byłoby stosować metodologię jaką wypracował w kernelu 2.2 
dzimi czyli kompeltowania grupy zmian w branchu po to żeby to poten 
jednym ruchem podsumowując opis zmiany przerzucić na HEAD.

W sytuacji kiedy mamy dosć luźną organizację pracy takie "kapsułkowanie" 
zmian z jednej strony pozwalać będzie lepsza organizację prac w grupie 
zainteresowanej konkretnym keirunkiem zmian, z drugiej pozwoli ukryć 
wszyztkie drobne korekty w jakei trzeba bedzie wprowadzać w sytuacji kiedy 
różne szczegóły będą wychodzić w trajkcie prac nad grupą pakietów, a z 
kolejnej pozwalać beą na jednak w mairę stabilen wprowadzanie zmian na 
czele zmian.
Pzrypominać poeinno to prace prowadzone nad kernelewem gfzie czy to osoby 
czy to grupy osób pracują nad posszczególnymi podsystemami wrzucajac 
wyniki swoich prac do głównego drzwewka w momencie kiedy stwierdzą że 
grupa zmian jest juz możliwie kompletna (nie koniecznie zuopełnie 
kompleta i bezbęłdna ale nei jest takze kompletnyc eksperymentem).

Podobnie było z kde 3.x kiedy próbował to koordynować blues robiac to 
własnie wstepnie na branchu.

Owszem taka korekta nieco (naprawdę w małym stopniu) komplikuje prace ale
prosiłbym spojrzeć na sparwę racjonalnie i bez emocji bo takie podejscie
racjonalizuje większe zmiany jednoczenie nie blokując ich w żaden sposób.

Jednoczęsnie jeszcze raz .. prośbna o nie wymyślanie kolenych nazw 
branchy. Jeden DEVEL na eksperymenty wystarczy.
Używanie tylko jednej nazwy brancha powinno także uproscić przebudowywanie 
tego na builderach Nest.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*