State of the archive

[Daniel Stone]

On Tue, May 02, 2006 at 04:23:06PM -0400, Kevin E Martin wrote:
> On Tue, May 02, 2006 at 12:58:57PM +0300, Daniel Stone wrote:
> > On Tue, May 02, 2006 at 03:52:51AM -0400, Kevin E Martin wrote:
> > > - Release candidates are useful during development but should not be
> > >   pushed to FTP mirrors.  This could be solved either by adding a new
> > >   dir named "archive/development" for the RCs, which is never mirrored
> > >   to ftp.x.org, or we could create a new "development" archive where RCs
> > >   could be placed (e.g., /srv/xorg.freedesktop.org/development).
> > 
> > Hrm.  Can you please explain why, given that we mirror the individual
> > directory?  I don't see why we should avoid mirroring the RCs if we
> > already mirror the individual directory, unless you're talking about
> > bandwidth/disk space concerns, which is understandable.
> 
> Sure.  My reasoning is that RCs are not actual releases; rather, they
> are simply candidates and are intended for developers to try out and
> stress test to find bugs before making an official release.  They are
> not supported in any way and we don't want people using them out after
> the official release has been made.
> 
> As for the individual directory, it is the place for maintainers to make
> unbranded releases of their packages as needed.  However, if maintainers
> want to make RCs of their packages, then perhaps we need to have a
> "development/individual" tree as well as "development/X11Rn.m-RCq"
> trees.  If we did this, then maintainers could make snapshot releases of
> their packages in development/individual tree without having to worry
> about end users being confused with what is or isn't the latest stable
> release.

I can see the logic behind this.  I'm happy to have a separate
development/ directory in the archive.  Probably worthwhile following
this structure:
releases/
  X11R7.0/
    .../
development/
  X11R7.0-RC1/
    .../
individual/
  app/
  .../

> > > - The X11R7.0 dir is meant for officially branded packages (i.e., those
> > >   with the release version in the name) while the individual dir is
> > >   meant for the unbranded packages.  Unfortunately, the unbranded
> > >   packages were accidentally put into the X11R7.0 dir as well as the
> > >   individual dir.  They should be removed from the X11R7.0 branded dir.
> > 
> > I've cleaned these up too.
> 
> I think we're talking about different things.  For example, I still see
> things like:
> 
> xdpyinfo-1.0.1.tar.bz2
> xdpyinfo-1.0.1.tar.gz
> xdpyinfo-X11R7.0-1.0.1.tar.bz2
> xdpyinfo-X11R7.0-1.0.1.tar.gz
> 
> in the X11R7.0/src/app dir and similar tarballs in all the other dirs.
> The branded tarballs are the ones with "X11R7.0" in the name, whereas
> the others are meant for the individual dir where the unbranded tarballs
> live.  Since we already have xdpyinfo-1.0.1.tar.{bz2,gz} and similar
> tarballs in the individual/* dirs, we just need to remove them from the
> branded X11R7.0 hierarchy.  It was an unfortunate mistake that the
> unbranded tarballs were put into the branded X11R7.0 hierarchy, but we
> can clean this up now.
> 
> Basically, the rules that were worked out during the modularization
> effort last year were that when an official release is made (e.g.,
> X11R7.1), branded tarballs are created with X11R7.1 in the name and are
> put in "X11R7.1".  And, the unbranded tarballs are put in the individual
> dirs (if they aren't there already).  Distributions and vendors that
> need to track the branded tarballs use the "X11Rm.n" dirs and the ones
> that want to track the latest releases by the maintainers use the
> individual dirs.

Right.  I tried to clean these up earlier, but unfortunately I had ls
--color (historical damage), and rm -f, so it silently failed to remove
anything useful.  I've *really* cleaned these up now.

> > > - Older releases should be read-only so that they cannot accidentally be
> > >   overwritten --  note that some are already read-only but not all.
> > 
> > Erm, all the non-RC old releases that I could see were read-only.  Do
> > you mean the R* -> X11R* symlinks?
> 
> Looks like only 6.9 and 7.0 are read-write.

Right.  Is this not what you want?

> > > In the mean time, I suggest that the current security patch for 6.9/7.0
> > > be copied to ftp.x.org, which should address the immediate concern about
> > > the missing security fix.  Also, any other fixes that are missing can be
> > > handled similarly as needed until the archive on annarchy is ready and
> > > the mirror is running.
> > 
> > individual/ as well ...
> 
> The individual dir is a large one, which is why I left it out.  Also, it
> looks like we're nearly done with the clean up (just a few more cleanups
> that I mention above that shouldn't take very long), so hopefully we'll
> be able to get the mirroring going in a couple days.  However, it would
> be nice to have the security patches mirrored today if possible.

Indeed.  That particular part is certainly long-overdue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060503/86afa6b9/attachment.pgp>