Proposed changes to the xorg archive

[Kevin E Martin]

On Mon, Nov 27, 2006 at 11:40:31PM -0800, Donnie Berkholz wrote:
> What is the purpose of the "src/" subdirectory? To me, that reads as if 
> we anticipate providing binaries at some point. If so, why is there no 
> "src/" subdirectory for the individual/ releases? Perhaps it's an 
> accident of naming, but this seems like an optimal time to fix it by a 
> rename to "branded" or similar.

You're right, I was trying to make the minimal changes necessary to the
existing releases.  We've been using "src" for each release many many
years.  If you look at the current archive structure, there is a
binaries dir but we've never populated it (and it's unlikely that we
ever will).  Note also that I removed the index.html and doc dir that is
included with the releases so that we could only focus on the source
tarball organization -- in the full archive, these dirs will still
exist.

I'm not opposed to changing src to something else, but I'd like to do
this just once so that the mirrors we have don't have to keep changing
things, and I'd like the name to indicate that this is where you find
the source tarballs.  I really don't like "branded" but if you have any
other ideas, I'd like to hear them.

As for src vs. individual, these two dirs are parallels between the
branded releases (which are in the src dir) and the individual releases
(which are in the individual dir).  These are present for both major and
minor releases.  The difference is that for minor releases, there's
another parallel hierarchy that only contains the updated packages (in
"update" subdir).  See below.

>                                 I dislike the use of "official" for this 
> because it implies that releases by the individual module maintainers 
> are unofficial. I understand your goal of avoiding unnecessary 
> reorganization, but I think avoiding potential confusion is worth the trade.

The difference here is that we have "official releases by the individual
package maintainers" and the "official roll-up releases that are branded
and approved by the X.Org Foundation".  So, both are official, but in
different ways.  I was just referring to the ones that are official with
respect to the X.Org Foundation releases.  No disrespect to the
individual releases was intended.

> Also, I don't really like the lack of parallelism where updated packages 
> are a level deeper than non-updated packages. I would rather see an 
> additional directory added to non-updated paths called "release" or 
> something along those lines.

There is parallelism on two different axes here: the parallelism between
the branded and individual packages and the parallelism between the
updated-only and full set of packages.  The first parallelism is handled
by the src vs. individual dirs and the second parallelism is handled by
the top level (full set) and update subdir (updated-only).  I considered
several organizations, but went with this one because it allowed the
major and minor releases to look similar so everyone would know exactly
where to go to get the full set of packages for this release, and then
those that only wanted the updated set of packages could go to the
update subdir.

> Finally, how does this address one of your original points of it being 
> difficult to discover deprecated software? Perhaps addition of a 
> "deprecated" directory for X11RX.X releases would fix this.

Oops, guess I forgot to include that explanation.  Here's what I was
thinking: The problem with only including the updated packages is that
there's no way to tell if a package is deprecated.  Instead by including
a full set of packages as well as updated-only packages in a release, we
can simply remove the deprecated package from the full set -- i.e., if a
package was included in the full set in a previous release but isn't
included in the next release, then it would be considered deprecated.
Now, having said that, I think I like your idea of having a separate
deprecated directory better.  This would make the list of deprecated
packages explicit.  I'll incorporate that into the next set of changes
to the script.

BTW, I'll be leaving for the airport shortly, so I won't be able to
respond again until tomorrow morning.  I'll work on the script on the
plane and see if I can get another test archive set up with these
changes tomorrow.

Thanks,
Kevin