On Thu, May 15, 2003 at 05:19:17PM +0200, Matthias Urlichs wrote: > Hi, Sven Luther wrote: > > > On Thu, May 15, 2003 at 10:26:35PM +1000, Anthony Towns wrote: > >> No, it's sitting there, waiting for someone to use it. After a year's > >> neglect it might need some metaphorical oil on its hinges and some > >> dusting, but it really is there. I'm not just saying this for > >> rhetorical value. > > > That's great, However... > > > [ list of questions / possible problems ] > > My impression is that t-p-o is intended to be used like woody-p-o, i.e. > security fixes only, with a MNUish version number.
So if 1.2.3-4 is in testing, we upload 1.2.3-4.1.sarge ? > > So, the right and easy solution for the samba security bug is to upload > > the source package to testing-proposed-update, and it will get rebuild > > on all testing supported architectures in time. > > > Is that automatic, or does somebody have to push a few buttons? Anthony claims that it is automatic, i have not tested it yet, and had to rebuild a package myself some time ago, but that was for woody-proposed-updates, and only on some architectures. > > What happens then, will it stay apart, or get transitioned into testing > > when all arches have rebuilt ? > > > IMHO: The latter. > > > Also, should we use this only for security fixes, or also for other RC > > bugs or even non RC bugs ? Where is the limit and if there is one, who > > will enforce it ? > > > IMHO the automatic system should make sure that the version number of the > t-p-o package is between that of the current testing version and that of > the current unstable, to ensure that the package will eventually be > replaced with the one in unstable. Yes. > Also IMHO, a good rule-of-thumb is "security fix, OR it fixes an important > bug AND the regular update into testing is stalled". Ok with me, altough this could be used to work around some of the more important stalls. > The automatic system should make sure that testing itself doesn't get > hosed; it already does that job for unstable. I would like to propose one > modification, in that the resulting binary packages need to be able to get > from t-p-o to testing on their own, otherwise they're deleted. What about multiple packages that are interdependent and are uploadoaded with a few days (or hours or minutes) interval ? > Developers' laziness should make sure that the system isn't abused for > spurious pseudo-updates. ;-) But then, they could decide to upload to testing-proposed-update only, and forget about unstable ... Friendly, Sven Luther
