On Tue, Jun 11, 2013 at 10:29:33AM +0200, Philipp Kern wrote: > Chow, > > am Tue, Jun 11, 2013 at 09:15:48AM +0800 hast du folgendes geschrieben: > > > On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote: > > > > So, I think the developer should have a set of tools (including gb and > > > > even "slight" removal commands), which allow him to do the most of > > > > packaging work without worrying other teams/developers. And, of course, > > > > those tools should be relatively secure not to break others work and the > > > > whole archive. "gb" is a harmless in this case. > > > it is not. If you rely on random successes of your build this is worse > > > than not > > > providing a build at all. If there's a security issue, people will be > > > forced to > > > spend time on the issue. Either the Security Team or by extension the > > > Stable > > > Release Team, to get it built to finally include it into a point release > > > or > > > leave it lingering forever in p-u-new because a test case fails. > > It's not always the case of relying on random successes of your build. > > There are > > valid cases -- for example, if a build-dep, or a dep of a build-dep had a > > bug > > that prevented installation, and has just been fixed. > > I said random, not deterministic. Giving back until a certain test succeeds, > for instance. Because some bad code triggers a segfault on almost every try > except that it sometimes works.
That's a rather extreme case. I'd expect any approved DD to know better than to do something stupid like that. -- Kind regards, Loong Jin
signature.asc
Description: Digital signature
