On Thu, 2008-02-28 at 11:58 -0500, Bill Nottingham wrote:
Mike Bonnet (mikeb(a)redhat.com) said:
> If a transient build error (build system hiccup) prevented the build
> from completing, you should be able to rebuild from the same tag.
>
> Yes, I know there are some failure modes where this does not work, but
> we're working on addressing those, and they should be the minority of
> cases.
True, but if it's something like 'a build dependent package is broken',
you're unlikely to remember to just re-push the task two days later
when it's fixed.
I don't see how disabling force-tagging has any effect on this.
Remember you can rebuild with the same tag if the build fails.
In any case, turning off force tag would lead to
either:
- needless release & changelog inflation
Do we require people to add a changelog entry for *every* increment of
the release number? If you're just bumping the release for a rebuild,
it seems reasonable to not bother with the changelog entry.
or
- usage of scratch builds just to test that it builds everywhere
If the build fails because of a problem with a dependent package, you
can rebuild from the same tag once the dependent package is fixed.
If the build fails because of a problem with the spec file or source,
you need to change something to make it build successfully. Bumping the
release and adding a changelog entry seems appropriate in this case.
I'd argue that even *now* we should be discouraging force-tag in this
case.
Actually, do we even know if disabling force tag can be worked
around?
Not sure what you're asking here. There's no reason force-tag is
required for any part of the package maintenance workflow.