Jonas Smedegaard <jo...@jones.dk> writes: >> Maybe one consideration is that we COULD assume that the drive-by >> uploader is acting in good faith and has done her homework and has a >> better upload to offer than what you (or me) could ever have prepared? >> >> Rather than to assume they upload brokenness. Which I think is somewhat >> implied in your description. (And to be fair, probably often a correct >> assessment, but hey, we needn't assume that before it happens.) > > I already did. > > I was not describing sloppy drive-by, just drive-by. Me not releasing > the newest and most shiny upstream has to offer might be due to some > knowledge that I have as maintainer and that even a careful and 100% > well-intended driver-by could not have.
Right, this is common, but I'm not sure the consequence of this has to be that nothing can't happen without getting a reply from maintainers. A drive-by that uploads latest and greatest shiny that break things will likely result in the most critical consequences getting public attention more quickly, wouldn't it? And that seems better to me than things being stuck in some maintainers' internal process. Some Go packages are behind upstream versions, and I know of many reasons why uploading the latest version will break horribly, but still kind of wish someone would just upload them anyway to trigger sorting out the breakage earlier rather than later. Trixie shipped a bunch of old Go packages and maybe it would have been better to just throw the latest version of everything into unstable much earlier and sort out the problems instead of waiting and waiting, and trying to deal with the consequences of shipping old versions. We are still waiting and waiting even now because nobody has the time to take on doing the upload and be responsible for the mess. (To make this rant a bit more specific: golang-go.crypto, golang-google-cloud, golang-golang-x-net, golang-golang-x-sys, and a bunch of others.) > My point is, that someone looking at "the facts" may miss some relevant > information that is not materialized as public accessible facts. There > might be true benefit in talking with the maintainer about the > maintenance, not (in truly good faith) assume that communication is > irrelevant before upload. I've seen too many times, in many organizations, where people block other peoples work for (at best) unclear reasons, and things stall and create frustration on all sides. >> I find that often when I delay uploads because I'm thinking about some >> complex problem, I often run in circles and things never conclude. And >> sometimes in these situations, just uploading something that may be >> half-broken and sorting out whatever critical issues arise from that, >> can be better than waiting for a perfect solution to materialize. >> Making it possible for others to do that upload, to trigger things to >> happen, allows progress. Preventing others from being able to do >> uploads cause stagnation (which is sometimes desirable). > > You write "often" and "sometimes" above. And conclude that progress is > a net positive. > > My concern is that "rarely" or perhaps even "sometimes" progress sped > up by skipping human interaction is a net negative. > > I question if running fast and breaking things is what we want to aim > at in Debian. I think a better way to mitigate the negative aspects of "run fast and break things" is to improve QA tooling and make it part of our processes. Rather than to insist on maintainer +1 before any drive-by upload. If the unstable->testing migration would give a -3 day migration discount to a green Salsa CI and a +3 day penalty for lack of Salsa CI I suspect we'd probably get more Salsa QA usage. So I think it should be fine to (well-intended, of course) "run fast and break" things in experimental and unstable, and invest in strong QA tooling that don't let the damage slip into testing. > I am pro collaboration. I am not pro skipping the communication part of > collaboration. Maybe that makes me some kind of protectionist, but I > think that is accidental - I think that is because we are discussing > one single means of progress here, not discussing more broadly how we > want to collaborate in Debian. Maybe we actually mostly agree, and are just discussing semantics how the communication should happen. I am open to consider a drive-by upload to unstable as a way to communicate amongst DD's. Upload ping-pong is horrible, but I think it is rare. We are all supposed to help all of Debian, not just the particular sub-part of Debian that we "own", right? /Simon
signature.asc
Description: PGP signature
