musings on "the release thing"
In article <[🔎] 19980529083228.A7451@molec3.dfis.ull.es> you wrote:
: IMHO, that method would be easier to follow if we divide "main" in "core"
: and "non-core".
So, how does that differ from the current system? Isn't "core" exactly the
same as the set of required+important priority packages? One could argue
that the core also includes standard packages, but I see that as a second
tier, with all of optional and extra as clearly not part of the core.
But even this is just a testing optimization thing. To do a 'stable release',
the "release team" would still want/need to determine which packages from the
set of all available packages should be included in the release, and which
version of each package to be released should be included. If it helps the
testing team to start with packages in the highest priority band and work
out from there, that's fine, but I don't think it should change the release
process.
I've been thinking about this a long time. Here's a wild idea I've been
kicking around for a long time. If you don't have time to be distracted,
quit reading now!
A long time ago, when I instigated and for a while managed master.debian.org,
I was on the verge of proposing a radical change in the way we handle
versioning... then I got massively busy at work, went through a messy
internal audit that forced me to be less generous to Debian with our network
bandwidth, and so forth... so I never followed up on the idea. I have
alluded to it a couple of times, and I still think there's a kernel of a
good idea in here somewhere.
The general notion is that all package uploads go into a common pool.
Scripts on the server routinely build a symlink tree that points to the most
recent version of each package in the pool, which is the equivalent of the
current 'unstable' tree. In fact, there could even be different flavors of
instability, with different criteria used by the link tree builder to
determine which versions to link to for each tree. Trees of symlinks are
cheap.
When the calendar, or the release team, or God decrees that it's time to work
on a new "stable release", a new versioned symlink tree is semi-manually
built pointing into the package pool, identifying the versions of each
package that are proposed to be included in the release. Testing ensues,
and the versioned symlink tree is updated appropriately based on the results.
At release time, the versioned symlink tree is frozen. The size of the pool
is managed using standard resource allocation techniques... any version of a
package currently being pointed to is retained, prior versions of packages
are retained as allowed by available disk space, with older bits being
deleted to make space for new bits arriving.
There are some obvious issues surrounding how a structure like this gets
mirrored, but it has several technical and procedural advantages. I always
hated the Perl/FTP mirroring code, and figured that doing something radical
with the dist tree that wasn't well supported by the traditional mirroring
techniques might motivate me to go write a suite of tools to do the job
better. One of the really cool aspects of a structure like this is that there
is very little risk in trying a new rev of a package, since with sufficient
disk space on the archive, there would always be a few prior revs to fall back
on as need be. It also makes it really easy to live on the bleeding edge,
since latency from upload to mirroring could be very small.
One specific failing of the current system that I lament is that any new
package installation into the distribution tree causes us to lose the previous
version. This makes fallback tough, depending on the maintainer or other
random folk to be able to reproduce/reupload a prior version of a package.
It also causes us to be wickedly cautious about installing new packages... my
vision would have Incoming packages dropped into the pool immediately if the
signatures and sums all matched for a registered developer... I'd also drop
the notion of subsections entirely, and merge the 'standard' and 'important'
priorities into one priority.
I still don't have time to work on this idea... if I did, it might be the
genesis of a yet-another Debian-derived distribution... since it would be
easy to track unstable and Incoming to seed an independently managed release
tree even if Debian didn't adopt the notion... and I suspect it's radical
enough to be a tough sell these days... too many developers to convince!
As my current-favorite game says on the box... "so many pedestrians, so little
time..." :-) Or, as the HP calculator software guys used to say, "life is
short, and the ROM is full"... :-)
Bdale
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: