Hi Christian, Christian PERRIER <bubulle@debian.org> (2016-11-21): > 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). The problem is two-fold: - we need people to fix breakages that are reported. - we need to detect those breakages. We're slowly getting more automated testing, but there's indeed some workload as far as keeping stuff working goes, on both topics. > 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. Given we're slowly progressing through the release cycle, I think it would be better at this point to have commits staged but not uploaded instead of stuff getting uploaded without “after-sales service”. People pushing changes should be encouraged to take responsibility and upload themselves instead of waiting for someone to do that; with that someone being you… (As I tried to convey in my first mail: I'm very happy you're still spending time on d-i after all these years; but I also think we need to find something that works a little better, and doesn't make you feel like the one responsible for regressions.) > 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. I'm not sure the problem is about quickness; probably more about the contents of the changes. Speaking of which, I'd like to get more traction on the l10n front (4 languages uptodate right now…), maybe we'll be able to find something that works fine to get work (translation) done and uploaded… KiBi.
Attachment:
signature.asc
Description: Digital signature