State of the archive

[Egbert Eich]

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

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?


Cheers,
	Egbert.