State of the archive

[Kevin E Martin]

On Wed, May 03, 2006 at 03:25:22PM +0300, Daniel Stone wrote:
> 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/
>   .../

This seems to me to make "individual" appear as if it isn't a place
where releases are made since it's not part of "releases".  I think
keeping the official releases at the top level along side individual
would be better:

development/
  X11R7.0-RC1/
    .../
  individual/
    .../
X11R7.0/
  .../
individual/
  app/
  .../

This way we have all releases on equal footing.  And, in the development
dir, we have RCs (for both individual and rollup releases) as well as a
place for individual package maintainers and release managers to put
snapshots for packages that haven't been officially released yet.  As I
mentioned earlier, this would help avoid end-user confusion over which
package is a development snapshot/RC and which is a stable released
version.

> > > > - 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
...
> 
> 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.

No problem.  It looks good 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?

Shouldn't all releases, including the current ones, be read-only?  I
wouldn't want an accidental overwrite to happen to happen with those
releases either.  It just seems prudent to make everything read-only.

> > > > 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.

It looks like all of the patches from annarchy are ftp.x.org, so this
part was taken care of.

One thing I noticed while going through the patches dirs is that we have
one on ftp.x.org that isn't on annarchy, which should be:

  X11R6.8.2/patches/xorg-CAN-2005-2495.patch

Almost there...
Kevin