Re: Archive Restructuring -- The dists/ Hierarchy
Anthony, thanks for the trouble and effort of putting this together.
I have a few suggestions:
* Provide a "life-cycle of a package" example, showing how a package
could percolate from unstable, into the pool, into prerelease, and
back out again, suppose. An example would make the proposal
clearer. Perhaps indicate maintainer activities and release-group
activities too.
* Would it be feasible to yank packages out of pre-release, supposing
no other prereleasee package depends on it, and it has had a
release-critical bug for >= 1 week ? This might reduce load on the
archive maintainers.
* BTW, I consider the additional effort that will be required by
archive maintainers in your proposal, assuming I understand it, as
one of the biggest flaws in it.
Do you think the BTS will have to be modified to deal with your
proposed system? What if an "unstable" version of a package has a
release critical bug, but the prerelease candidate (a lower version
number) does not? If the BTS/release process needs to cope with this
in an automated fashion, it might be sufficient for the prerelease bug
checking system to consider only bugs against version <= X, where X is
the prerelease version number.
I think we need to realistically assess whether we can meet increase
work demands, either on internal infrastructure such as dinstall or
the BTS, and the work load of the archive maintainers.
--
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: