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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1831094
Received on 2009-04-21 04:50:08 CEST