Wszystkiego dobrego

Mariusz Mazur mmazur at kernel.pl
Fri Jan 28 23:58:51 CET 2011


On Friday 28 of January 2011, Marcin Krol wrote:

> Pisałem przecież "Pomijając kwestię zarządzania uprawnieniami do
> repo"... ale mniejsza z tym.

Ja też napisałem, że była to kwestia pominięta przez ciebie. A właśnie ona 
jest w tym wszystkim istotna.

> Wynika z tego, że cały wątek możemy przekierować do /dev/null bo w obu
> przypadkach oficjalne PLD nie ma korzyści, a Titanium osiąga ten sam cel
> przy tych samych zasobach osobowych. Różnica jest więc czysto polityczna.

To by było prawdą, gdyby nie fakt, że w swojej argumentacji stworzyłeś 
sztuczne ograniczenie do dwóch możliwych wariantów. Inaczej sprawa wygląda, 
jak rozważysz wariant trzeci, czwarty, piąty i dziesiąty.

Wariant trzeci: twój deweloper chce sobie zupgrejdować coreutils (czy 
cokolwiek innego). Twój deweloper nie ma wjazdu do PLD, więc jedynym sensownym 
z jego punktu widzenia rozwiązaniem będzie zassanie coreutilsów od nas do was 
i zupgrejdowanie u was. PLD nie ma z tego nic.

Wariant czwarty: Ti jest na branchu u nas, ale tylko w przypadku różniących 
się pakietów, do których coreutils (nie sprawdzałem) się nie zalicza. 
Deweloper ma minimum zdrowego rozsądku i nie tworzy brancha Ti tylko po to, by 
zupgrejdować coreutilsy, tylko je upgrejduje na HEAD. Z pożytkiem dla 
wszystkich.

Wariant piąty: deweloper, który dołączył do PLD bo zainteresował się 
(branchowanym) Ti, jednak jest tym deweloperem PLD, więc jak jest potrzebna 
pomoc przy adminowaniu jakąś częścią wspólnej infrastruktury, to się zgłasza 
na ochotnika, dzięki czemu nie tylko Ti, ale i całe PLD mają pożytek z tegoż 
dewelopera.

I tak można jeszcze sporo. W każdym razie możesz próbować publicznie 
twierdzić, że deweloperzy, którzy pójdą do ciebie, zamiast do PLD, nie będą 
stratą PLD, ale nie sądzę, żeby dużo osób dało się przekonać. Fakt, że Ti 
działa w takiej formie w jakiej działa, jest imho całkiem sporym dowodem na 
elastyczność PLD względem swoich deweloperów. Ale ta elastyczność ma swoje 
granice i próba robienia pełnego forka na infrastrukturze PLD je na pewno 
przekracza.


--mmazur


More information about the pld-devel-pl mailing list