ANN: ruchy na ftp

[Fryderyk Dziarmagowski]

 --- Paweł Sakowski <saq w pld-linux.org> wrote:

> > > Czyli najwyższy czas ją sportować na AC-branch.
> >  
> > to byłby świetny pomysł, gdyby dotyczyło rpm, gcc, glibc, etc.
> 
> Wg `sed -n 470p devel-hints-pl.txt` to jest zawsze świetny pomysł.

chyba nadinerpretacja. nic nie pisze, że świetny.

> > Ogólna dysfunkcjonalność programu może dotyczyć każdej części
> > dystrybucji. Równie dobrze mogę to dopasować do wielu innych
> > krytycznych jej składników. udev nie jest takim składnikiem
> 
> Cokolwiek kontroluje /dev jest krytyczne.

Krycztyczny jest wybór, a nie wyimaginowane lęki.

> >  i nie jest
> > instalowane domyślnie,
> 
> Wg wersji HEAD jeśli chcesz korzystać z funkcjonalności udev (np.
> automagiczne inodey dla zabawek USB), musisz pozwolić żeby ci
> kontrolował /dev.

ja i wielu innych na tej liście nie ma z tym problemów.

> > > Odpowiedź#2: AC-branch powstał z jakiegoś powodu (szczegóły w
> > > archiwach). Ciężar dowodu, że ten powód już nie obowiązuje (i można
> > > skasować AC-branch i budować do Ac z HEAD) leży po twojej stronie.
> > 
> > AC-branch powstał w celu wydania dystrybucji. [ciach offtopiczne
> > narzekanie że jeszcze Ac nie wyszło]
> 
> Chodzi o AC-branch na udev.spec. Dyskusja /udev-vs-/dev już kiedyś była
> na liście i wynikło z niej, że Ac korzysta z /udev. I w tym celu powstał
> AC-branch, i dopóki on istnieje, z niego się puszcza zlecenia do
> ac-ready.

Dyskusja dotczyła niedziałającej wersji w powijakach. Rozmawiamy o
całkowicie innym udev.

Przytocz proszę jeden _merytoryczny_ argument, przykład niedziałania
wersji z HEAD, bug report, post na tej liście, a chętnie będę dalej
uczestniczył w dyskusji i rozwiązaniu problemów związanych ze zmianami
przeze mnie wprowadzonymi.

-- 
Fryderyk Dziarmagowski