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

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: