[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: On uploads and responsibilities

Quoting Cyril Brulebois (kibi@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

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.

Attachment: signature.asc
Description: PGP signature

Reply to: