Re: Archive Restructuring -- The dists/ Hierarchy
Hi,
>>"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
done?)
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
tested.
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.
manoj
--
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: