slrn-pl vs. slrn

[Tomasz Kłoczko]

On 6 Jan 2002, [iso-8859-13] Paweů Sakowski wrote:

> W liście z nie, 06-01-2002, godz. 15:29, Tomasz Kłoczko pisze: 
> > > Czyli jak, przykładowo binarka miałaby być /usr/bin/slrn-pl ?
> > 
> > Nie. Odpowiedni patch z modyfikacjami gettexta i polskimi tłumaczniami
> > powinien wylądować w slrn. Dokumnentacja many także. Po wszystkim takiego
> > patcha można posłąć maintainerowi.
> 
> Przecież było o tym, że część poprawek nie wszystkim się podoba.

Przecież napisałem o poprawkach do gettext i polskeij dokumentacji czyli 
części która niemal pewnikiem zostanie zaakceptowana przez maintainera.
Jeżeli coś z jakis powodów nie będzie pasować maintainerowi i argumenty za 
odrzuceniem bendą logiczne to pewne jest że coś jest nie tak tego typu 
poprawkami.
Tak czy inaczje poprawki na makra to nie jest coś co powinno sie kryć pod 
pl w nazwie bo związku z tym to nie ma żadnego.

> Ficzery z slrn-pl możnaby wyodrębnić i dopatchować do slrn (oraz
> podesłać autorowi), ale z całego slrn-pl powinien powstać osobny
> pakiet (slrn-pl) z:
> 
> /etc/slrn-pl
> /usr/bin/slrn-pl
> /usr/share/slrn-pl
> etc.

Zapomnij o robieniu tego w ten sposób. Zrób to tak żeby nie było potrzebne
tego typu powielania projektu. Jeżeli coś w tym co robione jest w slrn-pl
jest ciekawe/użyteczne/poprawne i widać to gołym okiem to nie widzę
przeszkód w integrowaniu tego w slrn dla PLD zanim jeszcze maintainer to
zaakceptuje. Możesz nawet to co się dzieje w PLD wykorzystywać do tego 
żeby takei poprawki mocniej testować zamin przekażesz je maintainerowi.
Możesz nawet próbować używać tego typu integracje w pakiecie PLD jako 
argument za właczeniem przy negocjacjach z maintainerem ("tu sie to 
sprawdziło ..").

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*