State of the archive

[Kevin E Martin]

On Wed, May 10, 2006 at 12:43:21PM +0200, Egbert Eich wrote:
> Kevin E Martin writes:
>  > 
>  > 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.
> 
> This would require anyone who would like to pick the latest
> version of a package to look both in the latest release dir
> and in individual/ and compate the dates.

No, that's not how it works.  When an official release is made, branded
versions of the tarballs are created and are put into the X11Rn.m tree
and at the same time unbranded versions of the tarballs are created that
go into the individual tree.  Inbetween official releases, package
maintainers can create stable releases and put them in the individual
tree.  So, the people who want to track the latest stable releases will
always be able to go to the individual dir and find what they need
there.

What adding the development tree does is to allow release managers and
package maintainers to have a place to put unstable test packages,
development snapshots and release candidates.  By separating the
unstable from the stable, it will help avoid end-user confusion.

Also, as with all releases (both stable and unstable), the package
version number is always incremented when creating new tarballs so they
will be distinguishable from one another and there should never be a
need to compare dates.

> I would argue that packages that individually released packages
> should ge guaranteed build on a distributed base line - as an
> update to a released package.
> This may not always be true if combined with a random older release.

Ah, that's a great point: How do we handle releases from multiple stable
branches and the HEAD?  Releases for some packages will probably always
be created from HEAD, while others will be created from multiple stable
branches.  For example, the xserver-1.0.[12] releases are from the 1.0
stable branch of the xserver tree, but with 7.1, we will create a new
1.1 stable branch and releases from it will be named xserver-1.1.n.
Should we distinguish them in the individual tree with separate dirs for
each branch or let them live in the same dir?  I lean toward letting
them live in the same dir.

>  > > > 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.
>  > 
> 
> I would argue that releases should be stable. Thus making the dirs
> read only seems to be appropriate. Some consumers are very allergic 
> to changes in the checksum of a released version as this may be a 
> sign of a security compromise.

Right.

> The other question is what we do about security fixes?
> The user who picks the latest release (or any earlier one)
> whould have to check for the availability of security fixes
> and apply them before building.
> Uneducated users may not do this and pick stuff that's insecure
> (and has a published vulnerability). With the modular tree it
> shouldn't be necessary to create a security release when something
> surfaces.
> Would it be reasonable to create a separate directory with symlinks
> to the version of a package included in a release or a security fixed
> version based on the respective release - as a convenience service
> for users?

I'm not sure I understand what you're asking for.  We already have a
directory associated with each of the modern official X.Org releases
(e.g., X11R7.0/patches), and we provide a patch against each release
affected in those dirs.  In addition, for modular releases, we also
create a new unbranded tarball for each affected package and put them
into the individual tree.  Are you suggesting that we also create
branded tarballs and put them in the X11Rn.m tree?  If so, then I think
that's reasonable for the modular releases.

Thanks,
Kevin

PS - We're still figuring out the last few details for how the archive
will work, but when it's all done, I'll pull together the explanations
into a document, which can live in the wiki.