On Fri, 2011-04-15 at 10:25 -0400, Kamil Paral wrote:
My understanding to the original design goal with depcheck was that once an update was tested and accepted ... it must not be revoked. The set of accepted updates must always be dep-free. If new builds are added to an update, those builds must represent a new set of -pending updates for testing. If another update lands in -pending, and causes problems with some previously accepted update ... the problem is with the new update, not with something already accepted.
Does this design goal still hold?
Yes, it does. Unless some update in the accepted set changes.
Even though the updates should not influence each other (all the related builds should be grouped together in a single update), it's naive to suppose it's always the case. If we presume that sometimes two different updates can influence each other (which is the main presumption of our whole depcheck testing in the first case, btw), then we have to clear the accepted set and start building it again when some already accepted update has been changed. Because it could have broken not only itself, but also some other already accepted updates.
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].
Once something has been accepted, it's known good and theoretically, that build will move out to updates-testing and no longer be in our queues for verification. If a new build is added to an existing update, it is tagged with -pending and treated as an entirely new set of builds, right?
That's the Level 2 (long-term) solution.
After we have the concept of ResultDB and we abolish the concept of sending emails to maintainers for every single change in depcheck results, we can do the proper solution as described by Josef. That means emptying the 'accepted set' if some update from that set has been changed.
When new builds are added to an existing update, the previous builds may have already moved on to updates-[testing] and will be automatically included in future depcheck runs. If they aren't in updates[-testing] yet, will bodhi remove the -pending tags from the previous builds, or will there be two versions of the same package still in -pending?
I suppose that if I have update "foo-1.1,bar-1.1" and then edit the update and replace "foo-1.1" for "foo-1.2", then "foo-1.1" should be untagged from updates-testing and "foo-1.2" should be tagged into updates-testing. Confirmation with lmacken needed. I believe this is exactly the kind of issues we've been hitting lately with Bodhi (untagging wasn't done right).
Agreed, I believe this is an important assertion we need.
Thanks, James