SPECS: gettext.spec (HEAD) autoconf.spec (HEAD) automake.spec (HEAD)

[wrobell]

On Mon, Aug 25, 2003 at 06:47:23PM +0200, Mariusz Mazur wrote:
> On Monday 25 of August 2003 13:57, wrobell wrote:
> > > A masz lepszy pomysl? Jesli nikt nie bedzie chcial poprawic to przeciez
> > > przez jednego xemacsa nie bedziemy w nieskonczonosc opozniac 2.0.
> >
> > imho puscic to na buildery z bcondem, a jak juz dojdzie xemacs na ac, to
> > puscic bez bconda. ot cała filozofia. po cholerę później odkręcać mmazurowe
> > commity?
> 
> Odkręcenie commitów to jest kein problem. Natomiast xemacs raz się (a) nie 
> budował, a drugi raz się (b) wywalało to coś przy budowaniu ac/am/gt. A gdyby 
> na ftpie wylądowały src.rpmy które by default się wywalają (bo trzeba 
> wiedzieć, że należy użyć bconda), to zaś ktoś inny by się czepiał :)
> 
> O ile mi wiadomo założenie jest takie, że na ftpie lądują takie src.rpmy, 
> które się budują, a nie takie w których trzeba zastosować wiedzę tajemną, 
> żeby się budowały (czytajcie: nie będzie puszczania pakietów z bcondami... 
> albo domyślnie paczka buduje się całkowicie, albo części funkcjonalności nie 
> będzie). Fakt, że mnie te src.rpmy ani grzeją, ani ziębią i w sumie nigdy nie 
> słyszałem, żeby ktoś z nich korzystał, ale już kilkukrotnie mi zwracano 
> uwagę, że trzeba o nie dbać. Jak trzeba, to trzeba.

ano trzeba. tylko tu chodzi o coś innego. wrzucenie z bcondami byłoby
_tymczasowe_. dopóki xemacs i emacs się nie zjawią.

tymczasem rozbijasz robotę na HEAD tym, którzy na tych pakietach pracują
(developerzy, nest). bo raz bcondów trza użyć, a raz nie.

    wrobell <wrobell at ite.pl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-pl/attachments/20030825/8f2aca54/attachment.sig>