State of the archive
Daniel Stone
daniel at freedesktop.org
Wed May 3 05:25:22 PDT 2006
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>
More information about the xorg
mailing list