Delay between cvs commit and build-request/build

[Michael Schwendt]

On Sun, 08 May 2005 17:53:07 +0200, Thorsten Leemhuis wrote:

> We had something like the following once before, I can't find it in the
> archives (did not search very long), but it is somewhere. 
> 
> The purpose of the "Fedora Extras CVS commits <fedora-extras-
> commits at redhat.com>" Mailinglist was/is to make it possible for others
> like sponsors, package reviewers or other interested parties to check
> the fixes/changes that were committed to cvs before they get
> build/published. With the build-system now working automatically most
> packagers (including myself ;-) ) request build directly after
> committing. So actually no real check before build/publish (the latter
> actually depends on sign-time) is possible.
> 
> Should there be a delay in this process somewhere? At least 24 hours for
> example? 

No. No mandatory delays, please. This would be considered too limiting.
If you need to work on your set of packages today, you don't want delays
that force you to wait until tomorrow before trying to build them.  Just
apply common sense when committing major changes, which may result in a
flood of comments or harsh criticism. I'm sure that whoever rushes with
build requests, would be ashamed if it caused trouble that could have been
avoided.

> Requesting build after commit is imho understandable and okay (if the
> publish can be canceled somehow) -- with this way you don't have to come
> back later to request the build (otherwise it might be forgotten if you
> touch a lot of different packages on one day). But maybe the packages
> should not be signed/pushed in the 24 hours (or maybe 48 hours) after
> the build-request/cvs-commit?!
> 
> Opinions?

A quick way to veto/block packages would be helpful, provided that we ever
need it. For instance, if changes are discovered, which would break the
repository [dependencies], blocking binary builds from being published
might be necessary. Ordinary message to fedora-extras-list might not be
seen by the release team.