Re: Compulsory +1s for buildsystem commits?

On Mon, Apr 20, 2009 at 10:56:02PM +0100, Max Bowsher (test unpriv account) wrote:
> Stefan Sperling wrote:
> > Meta discussion:
> >
> > We are relying on things like libtool to compile our tree, which has
> > been shown to have various problems that sometimes only show on
> > particular platforms.
> >
> > It is a pain to having to fix the buildsystem if it is broken for your
> > particular platform. Especially if it keeps working for everyone else.
> > When it happen to you, it's a huge time sink. I had to go through this
> > 3 weeks in a row recently, and nearly forgot what it a joy it can be
> > to be hacking Subversion. It was very demotivating.
> >
> > Given the amount of trouble we had with the buildsystem and our
> > various platforms in the past, I would suggest we make it mandatory
> > for patches to the build system to be tested on as many platforms
> > as possible *before* committing. The goal here is to prevent such
> > commits from preventing others to get work done they are in the
> > middle of doing.
> >
> > And "platforms" here has a higher granularity than *nix and Windows.
> > We need to test these changes at least on:
> >
> > - some Linux
> > - some BSD
> > - MacOS X
> > - Windows
> >
> > Now, I recognize that Windows uses a completely different toolchain,
> > but for simplicity, let's just assume for now that any change
> > to the buildsystem might affect any platform. We can flesh more
> > details out later.
> >
> > I.e., assuming this simplification, four +1's, one for each platform,
> > for any potentially troublesome buildsystem change are ideal.
> > If people time out (say, give them 3-5 days), then it's fine to assume
> > that the change can be committed.
> >
> > We don't have to rush changes in all the time. It is acceptable to
> > make a patch, send it to the list, relax, wait for +1s for up to
> > 5 working days, and commit it once everyone is happy. The world
> > does not end if your change gets in a week later then when you
> > made it. But it does end for people if the buildsystem breaks.
> >
> > Please, we cannot keep tweaking the buildsystem on one platform,
> > commit, and break things on other platforms. It's evidently been
> > happening too much.
> >
> > The build system *must* work, just like the test suite. It is important.
>
> I agree breaking the buildsystem is very bad for other people doing work
> and tracking trunk.
>
> On the other hand, I'm very much opposed to review-then-commit for the
> buildsystem on trunk. There's lots of kinds of changes that are possible
> with very little danger of causing problems, which enforcing
> review-then-commit might make people less likely to tackle.
>
> Instead I propose that we declare a policy that any committer has the
> right to revert immediately any buildsystem change that breaks their
> ability to effectively do development on their platform of choice, as a
> matter of ordinary routing, without fear of accusations of an over-reaction.
>
> Once that occurs, then its up to the original committer of reverted
> change to either recommit a fixed version of their original change, if,
> based on the reverting committer's emailed rationale, they feel very
> certain that their new version definitely is fixed, or, to submit the
> change for testing in a manner very much like you propose otherwise.
>
> I think this approach sets a good balance between maintaining the
> fluidity of development on trunk, whilst providing an easy recourse for
> developers who find the build broken out from under them.
>
> Max.

Sounds good, suits me just as well, +1.

Attached is a patch to HACKING, using some of your eloquently worded
text :)

Further comments? Do people agree?

Thanks,
Stefan