MozillaZine

Mozilla Firebird 0.6.1 Coming Soon

Wednesday July 23rd, 2003

In a posting to his weblog, Asa Dotzler discusses the forthcoming Mozilla Firebird 0.6.1: "We're planning on doing a Firebird release based on the Mozilla 1.5a branch. This isn't going to be Firebird 0.7 since we haven't met our goals for features and fixes but we think it's important to get the autocomplete crash fix (and a few other fixes) into the hands of all the people currently using 0.6.

"We've made the first round of builds based on the 1.5a branch and they're available for testing: Windows and Linux builds just made it to FTP so grab a build and let us know what you think."

Update: Some updated 0.6.1 candidate builds are now available. See Asa's posting to the Firebird Builds forum for more information.


#1 Oh boy.

by Gnu

Wednesday July 23rd, 2003 10:18 PM

Reply to this message

This is gonna be confusing. It's great we're getting a new milestone, but is this particular branching such a good idea?

#2 Re: Oh boy.

by asa <asa@mozilla.org>

Thursday July 24th, 2003 12:00 AM

Reply to this message

"It's great we're getting a new milestone, but is this particular branching such a good idea?"

It's a horrible idea! What were we thinking?! How could we be so foolish.

--Asa

#9 Oh boy.

by JBassford <jasonb@dante.com>

Thursday July 24th, 2003 5:49 AM

Reply to this message

Sometimes I wonder what this world is coming too...

#10 Oh boy.

by JBassford <jasonb@dante.com>

Thursday July 24th, 2003 5:51 AM

Reply to this message

I meant "to" not "too"! (See, just another example.) I really wish you could edit these posts as you can in the Forums. In fact, I wish that these main pages were also using phpBB. It would make life much simpler.

#3 fontconfig/xft

by bradfitz <bradfitz@bradfitz.com>

Thursday July 24th, 2003 12:41 AM

Reply to this message

Too bad fontconfig/xft still isn't in the Linux builds.

And <http://bugzilla.mozilla.org/show_bug.cgi?id=205621> really sucks, which I guess is yet another reason xft is still off... *sigh*

#6 try helping ...

by whiprush <jorge@whiprush.org>

Thursday July 24th, 2003 1:38 AM

Reply to this message

Come on brad ... where's the testcases for this bug? Debugging information? Anything to help the developers? Or are you going to sit there all day and sulk about it?

#4 Regressions.

by admiraljusti

Thursday July 24th, 2003 12:46 AM

Reply to this message

I think that going back to the 1.5a set reintroduces too many issues that had been solved.

#14 Problem with too many versions.

by neilparks1

Thursday July 24th, 2003 9:55 AM

Reply to this message

I don't understand the point of releasing new versions that lack numerous bugfixes that were successfully incorporated into previous releases.

The next milestone--call it "0.6.1" or whatever--should be whatever release has the most bugfixes, not the fewest.

#15 Should be some dashes

by neilparks1

Thursday July 24th, 2003 9:59 AM

Reply to this message

The msg I posted above was supposed to say:

(quote)

The next milestone (dash) call it "0.6.1" or whatever (dash) should be whatever release has the most bugfixes, not the fewest.

(end quote)

But the dashes (each consisting of 2 hyphens) disappeared.

#18 Re: Should be some dashes

by AlexBishop <alex@mozillazine.org>

Thursday July 24th, 2003 10:54 AM

Reply to this message

"But the dashes (each consisting of 2 hyphens) disappeared."

Added to the bug list. I suspect they're still stored in the database but they're being lost when the Talkback page is generated.

Alex

#21 Re: Re: Should be some dashes

by AlexBishop <alex@mozillazine.org>

Thursday July 24th, 2003 12:05 PM

Reply to this message

Fixed now.

Alex

#17 too many versions...

by mlefevre

Thursday July 24th, 2003 10:45 AM

Reply to this message

Rather duplicating the thread in the forums, but anyway...

What we want is a build with few bugs. The trunk builds have more bug fixes, but they also have new bugs which have been introduced recently. Rather than fighting a daily battle with new bugs, they're going back to a stable point and adding bug fixes to it. (The alternative solution would be to wait until the trunk is frozen, and that is the plan for 0.7 in a few weeks)

#24 too many freezes?

by pnh

Thursday July 24th, 2003 2:10 PM

Reply to this message

I think what we're seeing here is the beginning of the headaches with multiple products sharing the same (considered unstable) trunk. I know Camino is also in this position, and as TBird, SunBird and a host of other products get up to speed I think theres going to be a lot of managing checkins and such going around.

In light of that would it be wise to move some mozilla.org products to their own branches... or maybe step back and make some 1.4 based builds for a new stable baseline for general users?

#20 Re: Problem with too many versions

by asa <asa@mozilla.org>

Thursday July 24th, 2003 11:09 AM

Reply to this message

So if today's trunk build is crashing on startup but has more bugfixes than yesterday's build which isn't crashing on startup then we should release today's build.

--Asa

#5 am confused

by quarsan

Thursday July 24th, 2003 1:29 AM

Reply to this message

i gave up trying to figure out the trunk/ branch/ milestone thing a long time ago, but if something is posted as an improvement or something that has some fixes in, i grab it. and i've not been disappointed yet.

#7 Agree..

by naylor83 <d.naylor@swipnet.se>

Thursday July 24th, 2003 4:12 AM

Reply to this message

I am in the same situation as you. Don't quite understand the trunk/branch thing. Anyone who would find it easy to explain is very welcome to do so.

#11 Re: Agree..

by asa <asa@mozilla.org>

Thursday July 24th, 2003 8:31 AM

Reply to this message

excerpt from <http://www.mozillazine.or…articles/article2031.html> :

First off, here are some terms you should know:

CVS: the location of the Mozilla source code. tree: a set of files in CVS. the Mozilla source code. pull: to check out a tree from CVS. check in: to update files in CVS with newer versions that have bug fixes. trunk: the primary or main-line set of files in CVS where code is worked on. tip: the most up to date files in the CVS trunk. tag: a set of markers across files that allow for a pull of the files as they were when the tag was made. branch: a copy of trunk files, hosted in cvs.mozilla.org, that can be developed independently of the trunk. cut a branch: to copy files making a branch. freeze: a period when the tree is not open for checkins or when checkins must first be approved. fork: a copy of the source code, hosted outside of cvs.mozilla.org, that diverges significantly from the trunk.

So How Does Mozilla Development Work?

As most of you all know, mozilla.org makes "builds" from the Mozilla source code several times a day. These daily (or nightly) builds are the result of a "pull" of sourcecode from the server cvs.mozilla.org. Regular nightly builds are pulled from the "tip" of the CVS "trunk". This means that these builds include all of the most recent changes "checked in" to the CVS tip. We stop development each morning and create these builds to test the previous day's changes, verify that check-ins actually fixed bugs and identify any new problems created in the last day's work.

About every 5 weeks <drivers@mozilla.org> steps in to moderate risk for a few days on the development trunk and works to create a short-lived code "branch" from the trunk. All check-ins to the trunk during this "freeze" require approval from <drivers@mozilla.org>. As soon as we have a build that is stable and we have a handle on the handful of bugs that we've identified as most important to the Milestone, a branch is created. This code branch can be thought of as an independent copy of the code on the trunk at the moment of branching. As soon as the branch is "cut", the trunk is opened to development so developers no longer have to ask drivers for approval to check in changes. A few developers working with <drivers@mozilla.org> try to get fixes for the Milestone show-stopper bugs and get them checked in to the branch. During this work the majority of developers have returned to focus on the tip of the trunk. When drivers are satisfied that the Milestone branch is ready for consumption, a release tag is made on that branch. This tag is a marker on all of the files that need to be used in making the Milestone build. A build is made from that tag and released and the few people that were working on that Milestone branch return to work on the trunk. And that's the basics of Mozilla trunk and branch development.

--Asa

#12 date?

by pmsyyz

Thursday July 24th, 2003 8:46 AM

Reply to this message

Mozillazine articles should have dates on them.

#13 dates

by mlefevre

Thursday July 24th, 2003 8:58 AM

Reply to this message

September 27th, 2001. It is annoying that the "full text" pages don't show the dates, but if you look at the "talkback" page for the article (a link from the "full text" version at the bottom), that has the date.

#19 Re: dates

by AlexBishop <alex@mozillazine.org>

Thursday July 24th, 2003 10:59 AM

Reply to this message

"It is annoying that the 'full text' pages don't show the dates, but if you look at the 'talkback' page for the article (a link from the 'full text' version at the bottom), that has the date."

It's so annoying that we fixed it with the server move. All the new full articles (example: <http://www.mozillazine.or…articles/article3465.html>) have dates but the old ones don't. They're static pages so it ain't gonna happen.

Alex

#22 Re: Re: dates

by mlefevre

Thursday July 24th, 2003 1:02 PM

Reply to this message

Great. Nice to have that fixed.

However, the server move seems to have broken your example link <http://www.mozillazine.or…articles/article3465.html> is 404, <http://prod.mozillazine.o…articles/article3465.html> works though.

#23 Re: Re: Re: dates

by AlexBishop <alex@mozillazine.org>

Thursday July 24th, 2003 1:09 PM

Reply to this message

"However, the server move seems to have broken your example link <http://www.mozillazine.or…articles/article3465.html> is 404, <http://prod.mozillazine.o…articles/article3465.html> works though."

They both work for me. Your local DNS server probably hasn't picked up the server changes yet.

Alex

#26 Re: Re: Agree..

by naylor83 <d.naylor@swipnet.se>

Thursday July 24th, 2003 2:56 PM

Reply to this message

Thanks for the helpful reply!

#29 yes, but how does this relate to mozilla firebird?

by an_mo

Friday July 25th, 2003 11:02 AM

Reply to this message

What I'd like to know: if somebody checks in a patch to the mozilla trunk (say on parts of the code that are shared by mozilla and firebird), will this automatially be applied to the next firebird build as well?

#31 Re: yes, but how does this relate to mozilla fireb

by AlexBishop <alex@mozillazine.org>

Saturday July 26th, 2003 6:47 PM

Reply to this message

"What I'd like to know: if somebody checks in a patch to the mozilla trunk (say on parts of the code that are shared by mozilla and firebird), will this automatially be applied to the next firebird build as well?"

Yes. However, as Firebird 0.6.1 will be based on the Mozilla 1.5 Alpha branch, only changes that have been checked into the 1.5a branch will make it into this release.

Alex

#30 Re: [Development Glossary]

by LenW

Saturday July 26th, 2003 11:03 AM

Reply to this message

Thanks, Asa, for the glossary. Could you add what it means for something to have "landed" ? Thanks, -Len

#32 Re: Re: [Development Glossary]

by AlexBishop <alex@mozillazine.org>

Saturday July 26th, 2003 6:48 PM

Reply to this message

"Could you add what it means for something to have 'landed' ?"

'Landed' simply means that a patch has been checked into the tree, i.e. it will probably be in the next build.

Alex

#8 Agree..

by naylor83 <d.naylor@swipnet.se>

Thursday July 24th, 2003 4:12 AM

Reply to this message

I am in the same situation as you. Don't quite understand the trunk/branch thing. Anyone who would find it easy to explain is very welcome to do so.

#16 tab switch bug

by Tar

Thursday July 24th, 2003 10:09 AM

Reply to this message

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030723 Mozilla Firebird/0.6

Open Firebird, Ctrl+T for new tab, Alt+D to focus address bar, Ctrl+PgUp / Ctrl+PgDn - doesn't change tabs (focus document and it does change tabs).

Also, Alt+D, Ctrl+Tab and it first focusses the document area, second Ctrl+Tab changes tab.

Firebird just isn't so polished as Mozilla appsuite itself :/

Is it a confirmed bug? I sure didn't find it in bugzilla.

#25 Re: tab switch bug

by mozzmike <mikeweezer@interair.com.br>

Thursday July 24th, 2003 2:48 PM

Reply to this message

Try Ctrl-Tab and Ctrl-Shift-Tab, same feature, but no focus issue.

#28 Re: tab switch bug

by Tar

Friday July 25th, 2003 10:15 AM

Reply to this message

Yes there is if focus is at address bar, first Ctrl+Tab focuses the document and 2nd changes tab, since I use both Ctrl+(Shift+)Tab and Ctrl+PgUp&PgDn then FB isn't very comfortable to use on a daily basis.

Little drop of tar can ruin whole pot of honey ;)

#27 XFT

by nero

Thursday July 24th, 2003 11:19 PM

Reply to this message

Why isn't XFT enabled? And why is GTK1 used?