[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
  IF the operation in `THEN' has no incidence on other packages
   [AND the concerned bug would not appear after it has been applied
    remove `foo_Vn' from prerelease, and replace it with the latest
     [previous version still available, from a backup pool or latest
     [released version.
    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 ?)
      do the replacement, first moving all dependants back into the
       [staging area.
      require an ASAP fix, before which the (known bugg) unreleased
       [cannot be frozen.
  just keep it ;)

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

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: