I may be misreading, but I worry about breaking the design principle that the previously 'accepted' set is no longer valid and must be retested. Perhaps this is just confusion over wording though. I'm treating new builds to an existing update as completely new builds. They will have -pending and be in the queue for acceptance like all other -pending builds. I don't understand why clearing all previously -accepted builds is required? They've already passed testing, and at any time may be moved into updates-[testing].
There is a slight difference between adding a build and replacing a build (by a newer version). I was talking about the latter one. But in the end it doesn't matter I guess.
I understand your concern and proposed workflow. But depcheck.py doesn't operate on builds, it operates on updates (as opposed to the depcheck script itself). So let's have a hypothetical update:
foo,bar (update) ======= foo (build) bar (build)
When we detect accepted builds, we detect comment for "foo,bar" and hence we proclaim foo and bar as accepted. When we mark some builds as accepted, we mark the whole update, and that makes all builds inside it accepted.
We don't operate on builds. We simply don't have any approach how to distinguish that foo is accepted, but bar is not (e.g. because it was added later). We do per-update testing. Now. We could probably do per-build testing once we have ResultsDB. Then your approach would be possible.
Still, two problems remain: 1. Your approach works when 'bar' is added to the update. But if I replace 'bar-1' by 'bar-2', I can't claim 'foo' is accepted. It can have broken dependency now. => If one update may become broken, other updates may become broken too.
2. Even if we could claim that 'foo' is accepted and 'bar' is not, how the RelEng team can push the update? Does it make even sense?
What exactly is wrong about emptying the accepted set, if we don't spam maintainers? Of course I don't want to empty the set if it is not needed, but if we change an already accepted update, I don't see another way.
Also, I think in the future we won't interact with maintainers much. I think depcheck and upgradepath will be mainly RelEng-related tests ("give the proposed updates subset I can push"). The package maintainers will just receive some notice like "Your update was not pushed because...". But those details are not much important right now.