State of the archive

[Egbert Eich]

Kevin E Martin writes:
 > 
 > 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.

Yes, these are supposed to be temporary and will go away after a while
- that is at least when the next stable release is made.
Those are for development purposes and should probably not be mirrored 
at all.

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

Right.

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

I'm not sure I fully understand the system yet. Maybe I'm still thinking too
much in 'branded' releases.
Here is how I understand this:
The package maintainer may create stable releases of his packages at
any time. 
Each new version will have the 'teeny' version bumped.
When we make a 'branded release' we will bump (at least) the minor number.
Therefore a minor number is associated with one 'branded' release - or
if nothing has changed in the meantime - with all the branded releases 
since the last one the package has been modified.
Is this correct?
May the package maintainer bounce the minor version between branded releases
also? In my understanding it would make most sense if he didn't.

In this case a single individual/ directory will probably do the job.
The user is always able to find the latest bits easily from the individual
tree. 
For earlier 'branded' releases this is slightly more difficult. But it's
still possible as it only involves looking for the highest 'teeny' version
with the same major/minor version as the branded release.

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

Well, if I understood things above correctly this doesn't seem to
be necessary - it would be a 'onvenience feature' for the user which
could also be confusing.

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

Right. 

Thanks!
	Egbert.