Re: Archive Restructuring -- The dists/ Hierarchy
Manoj Srivastava writes:
> So the stages in a packages life are:
> ------------------------------------
I'd rename that to "stages in the life of a package with no
release-critical bug". Then I'll agree with it.
But we really have to handle the case where release-critical bugs
appear, and IMHO we should as precisely as possible set up the
algorithm that we should use to handle these.
> Yes, as long as an older version was still in pre-release. So,
> when a package gets promoted from the staging pool to the
> pre-release, the older version is kept around for a grace period, so
> that any bugs discovered in the new package can be acted upon. Of
> course if the bug affects the older package as well ....
Here are some points I think we should consider:
[I use: "A -> B" to denote the "A depends on B" relation]
* the "A -> B -> C" type of problem is not the only one. We may also
encounter "A -> B, and D conflicts with older versions of B", and
probably other types of problem. Let's admit that apt or pkg-order
will tell us when removing a package causes any problem.
Then a possible (start of an) algorithm could be:
/* Handling of removal */
IF a (versionned) package `foo_Vn' in prerelease cannot be kept
THEN
IF the operation in `THEN' has no incidence on other packages
[AND the concerned bug would not appear after it has been applied
THEN
remove `foo_Vn' from prerelease, and replace it with the latest
[previous version still available, from a backup pool or latest
[released version.
ELSE
LET `N' be the number of packages whose replacement as defined
[just above would be necessary for consistency.
IF `N' < a given limit (I suggest 5 or 10 ?)
[OR a decision is made (according to the constitution ?)
THEN
do the replacement, first moving all dependants back into the
[staging area.
ELSE
require an ASAP fix, before which the (known bugg) unreleased
[cannot be frozen.
FI
FI
ELSE
just keep it ;)
FI
Rules also have to be stated as to how to fill/cleanuop the `backup
pool'. Ideally, we should ensure that it is large enough to get, in
the case of a release-critical bug being identified, the unreleased
pool as little modified as possible. I may be mistaken, but this
ideal case would probably mean "keep all uploaded versions since last
release", which is mostly unacceptable.
Some possibilities I see:
* as already stated, just keep the previous uploaded version till
to-be-defined time-limit has been reached.
* basically do like the previous proposal, but allow a maintainer to
tell while uploading "do not use the previous one as backup - better
keep the one before", for cases when an obvious bug is rapidly found,
or when an upload is just a cosmetic fix.
* enhance the number of backups for a given package to 2 or 3 - more
than that would probably waste too much space, we have to draw a line
somewhere.
Any other ?
Note: the backup pool could be only optionally mirrored, so its size
should only be concern for the master archive.
> Adam> Do you think the BTS will have to be modified to deal with your
> Adam> proposed system? What if an "unstable" version of a package has a
> Adam> release critical bug, but the prerelease candidate (a lower version
> Adam> number) does not? If the BTS/release process needs to cope with this
> Adam> in an automated fashion, it might be sufficient for the prerelease bug
> Adam> checking system to consider only bugs against version <= X, where X is
> Adam> the prerelease version number.
>
> This is already a flaw. When people send in bugs, they may be
> using the released version; the bug fixes still go in
> unstable. We consider that good enough.
Yes, this is a flaw, which we started to discuss some time ago. I
think we should address it.
--
Yann Dirson <ydirson@mygale.org> | Stop making M$-Bill richer & richer,
isp-email: <ydirson@a2points.com> | support Debian GNU/Linux:
debian-email: <dirson@debian.org> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: