Re: Gdk-pixbuf 0.20.0 is released

On Mon, 30 Sep 2002, Jeff Waugh wrote:

> <quote who="Tomasz K?oczko">
> > In case like above it makes _much_ more harder automated detecting new tar
> > ball viersions on ftp (best is flat strcture like before).
> See:
> (ten most recent files + date)
> (rss feed of same)

Sorry but I want have if it is possible one method for detecting new tar 
balls for evry project .. not one for all and second for GNOME stuff.

Things like above is is kind wheel reinvention :>

I have few thousands rpm spec files with correctly filled Source URLs and 
one _small_ script which tries detect any new tar ball basing on data 
stored in rpm spec Source field. Very similar method uses Debian people.

> We're considering putting latest/ directories back in, have to work out
> the best place for them.
> > I can't find any disscuss about this (looking on "ftp (re)structure"|"ftp
> > new hierarhy"|"ftp new tree" points to nowhere or to very old messages
> > about previouse ftp changes).
> Just look for FTP in both gnome-hackers and d-d-l.
> > What does this improves ?
> The entire structure is far more scalable than the previous one -> now that
> we're actually making releases, we need a better layout to handle them. The
> various threads about the FTP site will explain why the current layout was
> favoured.

Sacalabilities with keep in mind minimal anount of changes will be much 
better. Why not use:<project> for latest version 



for store all archiv tar balls ?

In both cases will even simplify mirroring only latest resources by ommit
(olny) one directory or ommit directories by regexp.
I can undestand why it was performed but IMHO "implementation" sill isn't
optimal/best possible.

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]