Hi Ted, On Sun, Jul 28, 2019 at 04:26:34PM -0400, Theodore Y. Ts'o wrote: > When I say "defer" I mean for less than a week. 3 days so e2fsprogs > can enter testing, and then usually with the greater exposure, more > bugs get reported, and then a handul of days for me to fix up problems > and re-upload. If I re-upload now, it resets the unstable->testing > countdown timer, and it further bloats things like > snapshots.debian.org. I've already uploaded 3 releases in 3 days, so > I figured it might be considered polite if a batched up some changes > instead of continuing to follow a "add a git commit, push a debian > package release" pattern.
I understand this and was not meaning to put pressure on you. > How critical is it for rebootstrap.git to be returning a problem for a > handful days? I guess I'm missing something about why a few days of > it reporting breakage is such a big issue? It's not the isolated e2fsprogs. The issue is more a consequence of the current architecture: It performs around 130 builds and aborts on the first failure. Thus when anything fails, I'm blind to later failures. This may sound ok, but my experience is that some regressions are difficult to track down. A key technique in figuring such regressions is time correlation. Having a small time window of success -> failure and then checking what got uploaded in the interim. So no, this is not a boolean. It's a trade-off. Also note that during the freeze, a week is usually tolerable. Post-freeze a 3 day delay is less appealing. For these reasons, I just pushed it into rebootstrap.git to have you not worry. Thanks for your quick replies! Helmut
