MozillaZine

Mozilla Status Update

Friday July 7th, 2000

The latest Status Update has arrived at mozilla.org, with several weeks of summaries for the Mail/News, XPToolkit, Architecture, XML and DOM, Necko/Imglib and Composer groups, as well as updates for OS/2, XPCOM, XML Extras, Tru64 and IA64, and LDAP.


#12 The Build Bar Explained (From Alan's Perspective)

by asj

Saturday July 8th, 2000 7:17 PM

You are replying to this message

Sorry for the delay in responding I got caught up in some other stuff.

As was said by others the build bar is primarily for QA Testing and not for "regular" users. Typically I have tried to reserve thumbs down for a build that does not start at all or crashes so soon it to the task that it proves useless. Remember even on the mozilla.org page it says the nightly builds may not work at all and are for checking to see if a bug is fixed. Unfortunately the build bar line itself could never satisfy everyone's thoughts of what it should be. That is why I have tried to add extra information in the READ MORE link. From a general use standpoint from what I have seen and judging from comments from others we have not had a real good build in about a week an a half.

For those wondering, I gave some of the builds this week thumbs up for various reasons. I was going to give the build thumbs down for hang on startup until I talked other users. The reports basically said if it hangs try again (you did not even have to restart) it usually worked by the 3rd or 4th try. Mac was considered the worst, but people still got it to run. The back button problem on Linux builds for one day did not prevent other uses from using the build it just make it hard for them (I know that is a gray area). Maybe i was wrong, but it was hard call.

When creating the build bar I have several steps I try and follow: 1. I usually read netscape.public.mozilla.builds, n.p.m.seamonkey, n.p.m.general, n.p.m.qa.general, and n.p.m.qa.browser and others depending on time. Asa and a few others often put Smoketest reports in n.p.m.qa.browser.

2. I try and review the CVS checkin logs for the last day or so. Looking for any new features or comments about bugs being fixed after the daily builds have landed that could affect that day's builds.

3. I always show up in #mozillzine <http://www.mozillazine.org/chat> and ask around about the build. There are several people that often provide feedback. I want to say a big THANK YOU to those that do! Many of these people not only say if it runs or not, but also mention other important bugs that they feel people should be aware of. We can always use more help here.

4. When I create the build bar there is tool tip info over each image by platform with a few words. If you are using Mozilla to view Mozillzine's build bar you currently won't see the tool tip. We are waiting on bug 27828 <http://bugzilla.mozilla.org/show_bug.cgi?id=27828> for tool tips.

5. I encourage people to read information provided in the READ MORE section. Even if the build gets thumbs up that is where i will try and warn you of other known issues. If I have a bug number handy I will even include a link so people can watch an important bug's progress. In the READ MORE section I also try and highlight new features especially new feature added by outside developers to help remind people that others can contribute.

I would love to have more user input so the comments in the build bar can help protect users from known issues. Builds typically don't show up till about 12:00 or 12:30 central, but I don't get to #mozillazine to ask about them till about 6:00 p.m. central or so.

I agree the build bar can be deceptive if you just see a big "thumbs up" for a build. It may be that we need a few extra words on the build bar to indicate that this is for QA Testing or something.

Sorry this got longer then I expected, but I would love for others to stop by #mozillazine with more input.