Quoting Cyril Brulebois (k...@debian.org): > Christian, I'm very happy with your uploading l10n only changes so that > translation updates don't take too long before reaching the archive. But > when code changes are involved, maybe it would be better to poke people > having pushed code so that they take responsibility for their changes, > and so that you don't get to be pointed at when wondering who broke > what.
I'm always balanced about this and, up to now, try to have a look at code changes when I apply my "upload fast" policy. But, well, it's also obvious that I'm too much disconnected from the current development challenges....and thus may miss important potential breakages. So, on one hand that would suggest more deep care and investigation before uploading. On the other hand, fast uploading should, at least theoretically, reveal potential breakages (see recent debootstrap or base-installer stories).... and, indeed, it does. The main problem seems to be that we desperately lack manpower to *process* reported breakages....and thus take appropriate action (for what I've seen, Julien reverted the debootstrap usr-merge changes but probably only after he noticed that nobody else would take action). I don't really know what to do, indeed. Continuing to upload quickly is likely to lead to such situations. Poking people about their changes....will I really commit to do this, I'm not sure, given the (very limited) time I currently keep for this work. Stopping fast uploads : I'm fairly sure this would lead to "commits wait for ages to be uploaded" situations. I might adapt to something like "check non uploaded stuff, except l10n, on a weekly or monthly basis, and not daily". That would help avoiding "too quick" uploads. I'm however quiute sure that I can't commit to promise poking each and every person about their changes.....we also need everybody with commit rights to D-I git to be responsible and try to anticipate the consequences of their changes.
signature.asc
Description: PGP signature
