Hi Bastian, Would you say that for publicly disclosed issues, the 'open' approach of pu works better? Meaning:
1. debdiff gets reviewed on a public list, others have an opportunity to help review and point out a mistake, and the discussion is archived 2. the proposed updates queue has a public page[2] 3. buildd status and logs are public[3] 4. dak emails the maintainer and updates the PTS 5. the changelog can be found on packages.d.o [2]: http://release.debian.org/proposed-updates/stable.html [3]: https://buildd.debian.org/status/architecture.php?a=amd64&suite=wheezy Whereas the above is generally not true of the Security Team's process, which seems designed to be able to handle embargoed issues? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/524e0094.3060...@pyro.eu.org
