Seth -- I know we had talked about running repomanage on the devel tree, but
does it make sense to run it everywhere?  Or to run it on the needsign queue
before stuff moves over?  If so, I can look at adding that into extras-sign-push

Jeremy, in addition to what you propose, I would prefer to see "success" (queue
containing successfully built packages) being separated from "needsign" (queue
containing packages waiting for signing before release) and the release process
to ask package maintainers for explicit "clearance" or "retracting" before
pushing packages from "success" to "needsign".

Something along the lines of
# plague-client build <package>
=> Package is being built, ends up in "success" or "failure"
=> Package maintainer is being notified on status (success/failure email)

On success, maintainer issues
plague-client release <package>
=> package is being pushed from "success" to "needsign"
or
plague-client retract <package>
=> package is being removed from "success".

As a side-effect, this  would allow package maintainers to use the build system
for build-testing on platforms a maintainer has no access to.

Jeremy: Adding repomange to run overtop of the needsign path is fine by me.
Though did we ever get a decision made on how many revisions back of extras
packages we are going to keep?

Ralf: I don't disagree about wanting the buildsys to allow a packager to do test
builds and retract ones but implementing all of your RFEs will take some time.
if you'd like to help out with those implementations I'm sure write access to
the plague tree can be arranged. Are you interested?

Created attachment 117562 [details]
pass at a patch

Seth -- here's a pass at a patch to essentially do repomanage over needsign
(not actually using repomanage, since that was going to be weird to integrate
in unfortunately).  But since we only ever want to move over the "newest" from
needsign, I think it should get the intended result.  And it leaves the
question about whether or not we leave old versions available as a side
question that can be decided outside this realm.  

Granted, if we decide not to leave old packages available for extras, then the
far simpler solution is to just run repomanage as the next to the last step of
hte push.

We have been repomanaging the repos for quite a while now (keeping 2 versions
for released distro versions and 1 for devel) and if I read the code in
extras-push-new correctly, it also avoids pushing anything else but the latest
build per package from the needsign queue.

Michael, is that correct?  Do you consider extras-push-new being ready to
replace extras-push-all and others?  When all signers start using
extras-sign-new, I think this bug can be closed.

Yes, that is correct. Actually, extras-push-new deletes older builds
and then pushes what is left. Works for me. (If we got the repository
lock file, we would be on the really safe side -- see buildsys-list).

The patch from comment 4, which I didn't know about, is incomplete
and would not work as intended. Plus, it contains at least one
crucial typo: infolist.has_key(n) should be infodict. Enhancing
find_files() to drop old builds on-the-fly also was the first thing
I had in mind. Afterall, the code that finds all the rpms is available
already, so I wanted to reuse it, too. *But* since we _move_ the builds
and don't clean up the rest yet, the ignored buils would remain and be
pushed the next time the script is run. That's why I decided to implement
a real cleanup function, which could also be run independently to prune
the needsign tree.

The new scripts have been in use for quite a while already, and this should no
longer happen.