Developers Must Now Consider Mozilla Firebird, Mozilla Thunderbird and Camino When Making API Changes
Thursday January 22nd, 2004
In a newsgroup posting, Mozilla Firebird developer Ben Goodger, Mozilla Thunderbird developer Scott MacGregor and Camino developer Mike Pinkerton have announced that those making API changes to core components must now ensure that they do not adversely affect Firebird, Thunderbird or Camino. For most developers, this will mean monitoring the three applications' tinderbox pages to ensure that their checkins do not cause breakages, as well as searching a little further afield when looking for code affected by API changes. If a developer fails to follow these new rules, they will be required to fix any problems they cause or have their code forcibly backed out.
Friday January 23rd, 2004 12:34 AM
Remember the old days of Netscape where we had the dual-tinderbox page showing both the commercial AND the public T'box ? I would recommend making a special page allowing to see with one URL access only the status of the 4 tinderbox Mozilla, Firebird, Thunderbird and Camino. It will save a lot of time, will help people checking the tinderboxes. Can only be positive imho...
I have this one as a Web Panel in Firebird:
<http://www.bengoodger.com/software/mb/tinderpanel/> has the add link for seamonkey/fb.
I'm glad Ben, Scott, etc. steped up to the plate on this one. This is key to the success of non-Seamonkey projects.
I just hope the other devs embrace this and don't trash on you guys.
#5 Multiple reviews?
by jesse <firstname.lastname@example.org>
Friday January 23rd, 2004 2:13 PM
If a single patch requires a small change in each product, does it require reviews from Ben Goodger, Scott MacGregor, and Mike Pinkerton?
If a checkin breaks Firebird, how long does the developer have to fix it before risking having their code forcibly backed out? (I guess time amount of time could be unspecified because the severity of the problem could vary from Firebird crashing on startup to something obscure.)
Firebird is fairly lenient on this sort of thing. If the change is a repetitive app wide thing such as an interface method name changing or similar, I don't really feel the need to impose extra bureaucracy into the process. The timeframe policy is identical to Seamonkey.
#8 To make this work, lxr needs to work for fb/tb/etc
Sunday January 25th, 2004 1:15 PM
The /mozilla/ index is updated so rarely as to be nearly useless, especially when merging to recent checkins (not to mention that it's _slow_). The /seamonkey/ index does not cover the non-seamonkey apps (nor parts of seamonkey like libpr0n and nspr, for that matter). So at the moment, there is no practical way to ensure that your changes won't break the other apps.