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

Re: Archive Restructuring -- The dists/ Hierarchy

>>"Adam" == Adam P Harris <apharris@burrito.onshore.com> writes:

 Adam> * Provide a "life-cycle of a package" example, showing how a package
 Adam>   could percolate from unstable, into the pool, into prerelease, and
 Adam>   back out again, suppose.  An example would make the proposal
 Adam>   clearer.  Perhaps indicate maintainer activities and release-group
 Adam>   activities too.

So the stages in a packages life are:

 1) packaged and uploaded to Debian, waiting in an Incoming queue
 2) checked out by dinstall, (lintian check here maybe?) the PGP
    signatures match, and goes into the unstable pool
 3) wait in unstable for a perirod. Resolve bug reports.
 4) When there are no (non wishlist?) bug reports reported, and the
    package is rellease ready in the maintainers mind, the maintainer
    tags it as such and asks that it be moved to the staging
    area. (suggest a minimum bug free stay in unstable before this is
 5) In the staging area, dependencies are checked, and more lintian
    checks maybe, and when all dependencies are go, move the package
    into the "unreleased distribution". 
 6) In the unreleased distribution, the package may undergo informal
    testing, and exposure to a wider user base.
 7) a snap shot of unreleased is frozen. By this time, no packages in
    the unreleased have any release critical bugs. They are formally
 8) the frozen distribution is released, and becomes stable.

 Adam> * Would it be feasible to yank packages out of pre-release, supposing
 Adam>   no other prereleasee package depends on it, and it has had a
 Adam>   release-critical bug for >= 1 week ?  This might reduce load on the
 Adam>   archive maintainers.

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

	Also to be considered: what if there are other packages that
 depend on hte new version that we are yanking out of pre-release?
 Should everything be yanked? How far would that go?

 Adam> * BTW, I consider the additional effort that will be required by
 Adam>   archive maintainers in your proposal, assuming I understand it, as
 Adam>   one of the biggest flaws in it.

	Umm, how much is that? We already do the freeze/release
 part. We need to semi-automate the move from unstable to the staging
 pool (perhaps triggered by an signed mail message from the
 maintianer). The testing group should be involved in the move to
 pre-release; also, we need to automate running lintian, pkg-order,
 and other checks on packages in the staging pool.

 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. 


 Each honest calling, each walk of life, has its own elite, its own
 aristocracy based on excellence of performance. James Bryant Conant
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: