Proposed changes to the xorg archive

[Donnie Berkholz]

Kevin E Martin wrote:
> Since the X11R7.0 release, several people have asked for some changes to
> how our archive is organized.  The main complaints were:
> 
> - Not everyone uses the branded packages from the various releases
>   (i.e., the packages with the release version in the package name), and
>   with the large number of packages, it is not easy to directly download
>   or even find the unbranded packages.
> - For the minor releases (e.g., X11R7.1, etc) and release candidates,
>   only the updated files are present, so it is not easy to know exactly
>   which packages are part of a release.
> - For the minor releases, it is also not possible to tell if a package
>   had been deprecated.
> - Some packages were put into the wrong directory.
> - The absolute symlinks made mirroring the archive difficult.
> 
> So, what I've been working on is a way to address these and other issues
> with a minimal set of archive organizational changes, create a script
> that would allow an archive maintainer to maintain the archive in a sane
> state, and allow a release manager to more easily create releases.

[cropped to try to make things easier to parse]

>    archive/X11R7.0/src/app     
>
>    archive/X11R7.0/individual/app     
> 
> 3. For minor releases (e.g., 7.1, 7.2, 7.3, ...), we would have the
>    following directory structure:
> 
>    archive/X11R7.1/src/update/app     

>    archive/X11R7.1/src/app     
> 
>    archive/X11R7.1/individual/update/app     
> 
>    archive/X11R7.1/individual/app     

> Some of the benefits of this work are that:
> - it is easy to find either the branded or unbranded packages in a
>   particular release
> - it is easy to find which packages have been updated in a particular
>   minor release or a release candidate
> - it is easy for the release manager to create a new release candidate
>   since all they would have to do is to symlink the packages that have
>   been updated to the development/X11Rn.m-RCq/update/* dirs and run the
>   script
> - the script that I'm working on can also show which packages have been
>   updated after a particular release.

> If you have any questions or concerns, please let me know.  If I don't
> hear any loud complaints, I'll go ahead and update the official archive
> in the next few days and take over maintenance of the archive.

Kevin,
Thanks for taking on this nearly thankless and arduous task!

I have a few questions.

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

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.

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.

Thanks,
Donnie