MinGW builds fail with new Binutils

[nilson]

Why has the requirement for a Binutils candidate been imposed when Mozilla Firebird will not build with it?

[cls]

Why has the requirement for a Binutils candidate been imposed when Mozilla Firebird will not build with it?

Let's go with the obvious: the checkin fixed a build problem with SeaMonkey and building FireBird is not a pre-checkin requirement. (In fact, I believe there are several other threads which cover this fact.)
Since the bustage is FireBird specific, you should open a bug on FireBird to get the necessary changes in as the FireBird cvs partitions are locked.

[iarnell]

I'm starting to get curious about this now. Are regular mozilla developers getting hacked off with *birds? If they know that something in SeaMonkey is going to break Firebird, do they

1. not care
2. care, but can't do anything, so what the hell
3. really care, make the necessary changes and make a patch for the appropriate team to review and checkin

[alanjstr]

Some of A and some of B.

[iarnell]

And how soon before Firebird gets to 1.0 does this need to be changed?

[cls]

Your question is based upon a false presumption: that SeaMonkey developers know that certain changes are going to break FireBird. Given that some of us never build FireBird, Camino, Galeon or any of the other Gecko spin offs (nor are we required to do so to work on SeaMonkey), how would we know that a particular change will break product X? When mozilla.org decides to change the checkin rules for the mozilla tree, then you can expect to see the behavior change. Until then, the spinoffs and especially, the platforms without tinderbox coverage will continue to pay the price for piggybacking off of the SeaMonkey source tree where there are checkins which are not made with their project in mind.

[iarnell]

When mozilla.org decides to change the checkin rules for the mozilla tree, then you can expect to see the behavior change.

This is the bit I was trying to get to. Presumably it's going to take a bit of time for a whole bunch of people to become familiar with the *bird code. The sooner people are able to contribute, the better. Are people annoyed that they can't contribute or just don't care until they can?

[nilson]

Why has the requirement for a Binutils candidate been imposed when Mozilla Firebird will not build with it?

Let's go with the obvious: the checkin fixed a build problem with SeaMonkey and building FireBird is not a pre-checkin requirement. (In fact, I believe there are several other threads which cover this fact.)
Since the bustage is FireBird specific, you should open a bug on FireBird to get the necessary changes in as the FireBird cvs partitions are locked.

See bug: http://bugzilla.mozilla.org/show_bug.cgi?id=220433

[alanjstr]

When mozilla.org decides to change the checkin rules for the mozilla tree, then you can expect to see the behavior change.

This is the bit I was trying to get to. Presumably it's going to take a bit of time for a whole bunch of people to become familiar with the *bird code. The sooner people are able to contribute, the better. Are people annoyed that they can't contribute or just don't care until they can?

They can check the source out and build it, but they can't make checkins. There's nothing to stop them from filing bugs and attaching patches.

[Bernie]

Has anyone building Firebird with MinGW been able to verify that bryner's check-in tonight fixes the bustage? If so, please say so in Bug #220433. Thanks!

[nilson]

Affirmative.

[michaell522]

They can check the source out and build it, but they can't make checkins. There's nothing to stop them from filing bugs and attaching patches.

True. But there's nothing that says that anyone will look at the patches they attach. On a previous lot of bustage the patch sat around until there was so much discussion about it in the forums and elsewhere that Asa (who doesn't generally do much work on the code) checked it in.

The sooner people are able to contribute, the better.

People (e.g. Firebird developers) wouldn't necessarily agree with that. If you have more people contributing directly, it becomes harder to keep track of changes and ensure that Firebird doesn't end up with messy and/or bloated code. The large number of people checking code into Mozilla has led to various code management problems, and the necessity for code reviews and superreviews etc, which are a pain.

Are people annoyed that they can't contribute or just don't care until they can?

A bit of both - if they know a small fix is needed in Firebird so it doesn't break, they may be annoyed enough by the situation that they don't care enough to do the extra work of filing a new bug, attaching a patch, etc etc, particularly if the Firebird developers aren't responsive when they do that.

And there's the point that cls already made that developers don't necessarily know they've broken Firebird, as everything has to be tested in Seamonkey, and developers aren't likely to want to test in Seamonkey and Firebird (and Thunderbird, Sunbird etc etc)