M13 Builds Appearing
Friday December 17th, 1999
Branching has occurred, and we should expect M12 to be released either today or Monday. M13 builds have started appearing on the ftp site, and you can get the latest builds from our builds page.
Mozilla has improved greatly over the past two weeks, so if you haven't checked it out, try to pick up a copy of the release when it hits the ftp site.
#1 M13 Appearing
Friday December 17th, 1999 2:09 PM
Coolness! I realize that the Mozilla Devs have spent time hammering things out and they want to be careful about annoucing it, but. . .does know if M12 looks like a good enough candidate for Alpha? :)
#3 Re: M13 Appearing
Friday December 17th, 1999 2:40 PM
I'm calling it alpha. I've consistently referred to Mozilla as 'pre-alpha' in posts and conversation but starting with M12 (reguardless of what firstname.lastname@example.org or staff at netscape decide to call it) I'll be referring to this as an alpha product. I'm now using mozilla for at least 50% of my browsing at work and at home and 100% of my mail and news at home. I've never given that much time to a beta piece of software so I feel completely comfortable calling Mozilla 'alpha'.
Now on to your actual question... I've got zero inside information but from what I'm reading in public forums, (newsgroups, websites and irc) I'm guessing that M12 will be called Mozilla Alpha. Some one tell me I'm wrong (I'd rather be wrong than uninformed).
posted with Mozilla win32 M13
#4 thanks asa - sounds encouraging! (n/t)
Friday December 17th, 1999 2:43 PM
#5 Re: M13 Appearing
Friday December 17th, 1999 2:53 PM
Mmmh, M12 milestone is not out yet and we are already talking of M13?
I think there should be a clear distinction between milestone builds and the nightly pre-pre-milestone builds. Although Mail/news is not so mature that I would use it as my everyday mail client, M12 is a nice peace of work.. Oops, now even I'm speaking of M12 meaning a non milestone build :-)
Friday December 17th, 1999 3:03 PM
The M13 development cycle has begun. M12 is done except for the polishing up and the announcement. I'm using an M13 nightly build to post this. I did not mean to suggest that I was using the M13 release build. I'll try to be more clear in the future.
posted with win32 Mozilla M13 nightly build (1999121708)
#13 Re: M13 Appearing
Friday December 17th, 1999 11:09 PM
I'm not quite sure what the big rush to getting to Alpha is. I suppose it denotes some level of progress, but in reality the purpose of going Alpha is to broaden the audience of bug finders.
I'm quite pleased with the latest build I just downloaded and all, but it's not like they haven't got more bugs then they can fix on their plate now. Mind you, I don't think it's a bad thing to move this to Alpha, I just don't see the benefit to the project as a whole.
BTW, this post entered with Mozilla!
#2 M13 Begins
Friday December 17th, 1999 2:30 PM
Well, I've been playing around with it for about an hour now and it works. I'm probably going to stick with the late M12 builds for a few days while the developers carpool in the changes they've all been holding for a while. Early nightlies from each milestone have always been filled with little problems and regressions for me as many changes are plowed into the tree in a short period of time. So I ususally wait a few days for them to iron it all aout and get it stable again. But so far early M13 looks nice. :)
posted with win32 M13
#7 What's the difference?
Friday December 17th, 1999 3:16 PM
So what's the difference between M12 and M13 right now? Is M12 the "stable" release, while M13 is where all the new features go? Asa, what's the stability difference between the two right now, and what makes you want to use M13 instead of M12?
#8 Re: What's the difference?
Friday December 17th, 1999 3:26 PM
The M[n] are the milestones of the development. They represent just a state of the development, but are cleaned and polished so they don't crash as often and are pretty "safe" to use.
As M12 branching just happened, there is nearly no difference yet in the M12, M13 builds. But M13 nightly builds are going to be developed further and it is not sure that they all work perfectly.
The M13 milestone build will happen somewhere in mid January, if I recall correct.
#10 Re: What's the difference?
Friday December 17th, 1999 4:01 PM
Exactly. What he said. For the last week or so the nightlies in the M12 development period did not have many serious changes checked in. For the most part the developers are focused on polishing off remaining M12 bugs and working toward stability for the M12 'release'and not adding a bunch of risky new code. As soon as M12 is branched and the new M13 development period begins (last night I think) then all of the heavy changes that were to risky to make near the end of a development cycle will be carpooled in. This is a process where several major checkins all go in at once under controlled circumstances (other checkins are usually halted) so that any regression or full-on bustage can be quickly assesed and repaired. So there is usually a big push of new code including architectural changes and new features right near the beginning of the development cycle. If you look at the official M11 release you will see that M12 work had already begun and progressed significantly when the M11 release announcement was made. To sum it all up, the end of the 'M' development cycle usually does not see as much 'new' stuff as the beginning of the next 'M' cycle. The M12 'release' (the last of the nightly M12 builds) will offer superior stability to the early M13 nightlies but the M13 nightlies is where you'll find the newest goodies. posted with Mozilla (an M13 nightly) Asa
#9 bah, the original beta was supposed to be in July
Friday December 17th, 1999 3:39 PM
#11 Bugs again...
Friday December 17th, 1999 5:03 PM
Has anyone else run into the problem where new windows don't always dissapear when you click the X to close them (Windows)?
If I use the Daily Builds (M12 or 13) for any amount of time, this starts to happen (Never on the first window though).
I've seen it on 2 different computers (98 and NT) but the bug was just marked as "Worksforme".
#12 Re: Bugs again...
Friday December 17th, 1999 7:53 PM
Happens to me all the time, starting with the M12 builds a while back, I think.
I hope someone with a Bugzilla account can help isolate this ...
#14 Re: Re: Bugs again...
Friday December 17th, 1999 11:18 PM
Hey fitz, go get yourself a Bugzilla account! It's not like you've got to show a drivers license or anything. I've been posting on there quite a bit as of late, and I can assure you that I'm no C++ programmer.
It's actually pretty fun. Just be polite and specific and watch them bugs your reported get fixed. Gets you involved with the game. Heck, a nobody like me got to close out a bug tonight that I reported 2 nights ago.
-- Microsoft has a browser?
#16 Re: Bugs again...
Saturday December 18th, 1999 2:19 AM
are you using mozilla.exe or viewer.exe? I get it sometimes using viewer.exe. I won't be surprise if they would not pay much attention to a viewer UI problem ( With M12-nightly, I've almost totally stopped using viewer). If it is in Mozilla, maybe you should reopen the bug and add your comments.
#22 Re: Bugs again...
Saturday December 18th, 1999 8:56 AM
#15 Great First Impression
Friday December 17th, 1999 11:58 PM
I am using Mozilla now, for the first time. I downloaded it once a long time ago but it did not work. Although I have noticed some problems, I am very impressed. The speed is good and I like the appearance. Keep progressing.
#17 Re: Great First Impression
Saturday December 18th, 1999 2:30 AM
I'm impressed too, but I hope they still work on improving it though. It still takes up too much resources when loading anything HTML/CSS. On my 32mb RAM machine,it just slows to a halt after viewing one or two webpages (depending on complexity, maybe the leaks are causing this). As for the UI, I guess it depends on personal preference. Does anyone know where the XUL/CSS documentations are? Or are they not written yet? I really can't stand the colours. Have been hacking navigator.css, but found out that many of the stuff like colours in there seems to be broken.
#18 Re: Re: Great First Impression
Saturday December 18th, 1999 4:22 AM
this is because many of the colours are implemented in graphical form (gif files).
documentation on XUL is at mozilla.org/xpfe/xptoolkit
css is at w3.org
#19 Dogfood/PDT+/Alpha/M12 ???
Saturday December 18th, 1999 4:36 AM
I thought that for Alpha release, all dogfood PDT+ bugs have to be fixed. M12 should be Alpha, that's what everyone says. But there are some (I think they are about 29) dogfood PDT+ bugs open right now (make a query in bugzilla and search for new/assigned/ bugs with PDT+ in the status whiteboard and see yourself).
Does this mean Alpha is declared later? Or do they break with saying Alpha=Dogfood and call M12 "Alpha", as everybody assumes? When will "Dogfood" be really reached then?
#20 Re: Dogfood/PDT+/Alpha/M12 ???
Saturday December 18th, 1999 4:44 AM
Sorry, wrong number. I wanted to type "20", not "29". It's actually 17 new/assingned/reopened PDT+ bugs right now.
posted with Mozilla/win32/1999121612
#24 See n.p.m.seamonkey post
Saturday December 18th, 1999 10:00 AM
Here's part of what Jim A. Roskind had to say on n.p.m.seamonkey (this past Thursday morning).
Warning: The following represent my personal opinions, and the plans of a pile of Netscape contributors, and are not necessarilly that of the entire mozilla community. I can always hope that the plans will make sense to a lot of folks, and that they'll join us in this portion of the plan... but we're not mandating any of this outside the Netscape staff. I'm trying to combine both status, our plans, and some motivation for our startegy, and if I say something in a less than PC way, please at least flame me privately ;-).
We're now planning to branch for M12 on Thursday morning.
We haven't reached "engineering dogfood," but we're pretty close
Tree will probably partially open (post M12 branch) Thursday afternoon, but Netscapers will continue to act under an "approval required" rule till we reach dogfood.
With regard to *M12*:
We shut the tree down last Tuesday eve, 12/7, as part of an effort to produce a monthly stability checkpoint (M12). During the week we restricted our checkins to fixes for serious regression, *really* low risk items, and major usabality issues (where we had a strong handle on the risk of the fix). The bulk of the checkins centered on major usability bugs called PDT+ Dogfood bugs (discussed in next paragraph). The usability of the product went way up, and the stability also increased over the course of the week (last Sunday was a great build for me... I ran for many hours doing work). We had planned on branching for M12 today, but a last minute regression (landed Monday afternoon) stalled the closing actions, and we'll now branch tomorrow morning. We expect to do some verification on M12, fix any critical regressions that cheated thier way in, and then stamp M12 as done (I've heard rumors about Mozilla creating an alpha around M12... but that will be the topic of other email ;-) ).
A reasonable review of *dogfood*:
Our current near term goal has been to get do "dogfood" here at Netscape with Seamonkey. We defined dogfood as the ability to do browsing, reading and sending messages (the basic stuff that most folks do with such a product). Most critically, we were looking only for barely edible dogfood (goes back to the words of wisdom: "learn to eat the dogfood you produce"). We were willing to accept a lot of work-arounds and avoidance maneuvers to use the product (example: don't use the file->open dialog, just enter the URL in the URL box). We had a team of managers (Product Delivery Team, or PDT) triaging bugs that had the word "dogfood" in the summary, and agreeing the bug was a "significant usage stopper," or deciding that it could be worked around. Usage stoppers were marked PDT+ in the whiteboard, and less broadly critical bugs were labeled PDT-.
Simply put, the reason for striving so hard for dogfood is to get the entire engineering staff at Netscape using the product, day in and day out. History tells us that once we reach this critical milestone, that the quality of the product will be held consistently higher, and that critical bugs will get the attention they need much sooner (in part because they are discovered sooner, and in part because of peer pressure when a feature regression impacts your coworkers).
Progress review towards *dogfood*
Over the past several weeks we've driven down these PDT+ bugs (by fixing some bugs as new ones were found and injected). The count went on a weekly basis from 120, to 96, to 107, then 85, 73, 63, and most recently, on last Sunday night, to 40. Our objective goal (pulled gracefully from the air) was to get down to a mere 5 PDT+ bugs, and then "call it dogfood" (and presumably note that most of the development staff is using the product, most of the time (eating Mozilla's dogfood)). Not only was the last week spectacularly effective (going from 63 to 40, or a week's reduction of 23 PDT+ bugs), but this week has proved an even more agressive follow on. We are currently around 22 PDT+ bugs (do a query for "dogfood" in the summary, and "PDT+" in the whiteboard to see this list), and it is "only" Wednesday night of the week :-).
While we've made spectacular progress, the folks on the PDT (which includes me) have become nervous about our "count of 5" criteria, and are willing to settle for the subjective criteria that at least "50% of the local developmement staff use the product for at least 50% of their daily work.". Today in a Netscape Client development meeting, in excess of 50% of the attendees reported using the product more than 2 hours per day, but only about 25% were (as yet) using it more than 4 hours a day. We have high hopes that by next Wednesday we'll be "dogfood" by at least one of our criteria... and so we're going to continue to try to get there RSN.
Given the proximity that we have to the holiday's, and the desire to be consistent in our monthly checkpoint releases, we've decided to release M12 on schedule, and move forword with the plan given below. There is a big difference in purpose between our "dogfood milestone" and the "M12 Stability Checkpoint." One represents a feature status, the other is somewhat akin to a daily verification build. We expect that folks will "like" the M12 build a lot, but we don't want to delay that sample point waiting for the status we're nearing with dogfood.
Plan and strategy going foward:
Netscape engineers will continue to give a _very_ high priority to PDT+ dogfood bugs, and try to drive this count to "zarro boogs" (a programmer's approximation of zero bugs). The good news is that with only about 22 PDT+ bugs remaining, the number of critically involved engineers should be relatively small We'll live on the tip getting checkin permission from chofmann (with jar and brendan as backup approvers). The restrictions will allow folks to begin work towards beta, but will try extra hard to prevent regressions which would preclude reaching dogfood. The checkin approval, and carefully monitored carpool landings as appropriate, should help maintain stability long enough for us to hit dogfood (...at least that's the theory :-/ ).Engineering managers will continue to help focus their staff on these critical PDT+ dogfood bugs... and hopefully, we'll be there in no time (I'm guessing that we'll be there by Wednesady of next week :-) ... but I can't promise).
When we reach dogfood, we'll drop back to our standard "open tree" requiring only code review and bug numbers in the checkin log, along with the running of the smoke test. Here again we hope that we'll stay real near dogfood even as we see additional landings, or at least we'll correct back to dogfood ASAP when we err.
Our current plan calls for the next stability checkpoint to have a tree closure at midnight, Monday night, January 17th. We feel confident that January's M13 will be a checkpoint with quality well above that of dogfood :-).
If you like what folks at Netscape are doing, we would ask that you join us in getting approval for your checkins from email@example.com (or firstname.lastname@example.org, or email@example.com). We believe it is in the best interest of the seamonkey project to reach dogfood asap, and get on with developing the product, while we live and browse in the code. If you're using Seamonkey now, you'll be able to tell (looking up at the mail header, even if you have "brief format" set), that I wrote and composed this in Seamonkey. I hope you'll join us in both eating the dogfood, and making it taste better, run faster, and jump higher.
Hope that answers at least part of your question.
#41 Re: Dogfood/PDT+/Alpha/M12 ???
Monday December 20th, 1999 1:23 PM
M12, Alpha, Dogfood and PDT+ have gotten pretty confusing. They're all related, but not exactly the same. Here's how I think of them, maybe this will help.
M12: the Milestone build that follows M11.
Alpha: a label applied to a mozilla build by the mozilla community
Dogfood: a label applied to a Netscape Communicator build by Netscape
PDT+: a label applied to a bug by Netscape to indicate that the bug should be fixed to reach Dogfood.
So, we determine whether M12 is Alpha, and Netscape determines whether M12 is Dogfood. Confusing, but we didn't want to assume that mozilla's goal and Netscape's goals are exactly the same. Mozilla Alpha will be similar to Netscape Dogfood, but not exactly the same.
The "no more than 5 PDT+ bugs" is a Netscape goal; that's why you'll find lots of talk of PDT+ bugs in the context of Dogfood. Discussion on criteria for Mozilla Alpha are at www.mozilla.org/articles/article965.html and in the current mozillazine survey.
#21 This Rocks!
Saturday December 18th, 1999 7:05 AM
I'm posting this in the latest nightly (12/17) for Linux. I was surprised I was able to get it to go on RH5.2 given the fact that it is supposedly unsupported ;) So far, I'm finding this to be an incredible improvement over the previous Linux binaries I've tried (which was admittedly a long long time ago ;)
All of my work has been done in Windows 95 Builds, and while I still think they're snappier in terms of UI response, these linux builds have improved dramatically.
#23 glibc 2.0 ...
Saturday December 18th, 1999 9:46 AM
... is not thread-safe. For more information, check out the bugzilla thread. IIRC, the bug only manifests itself when dynamically loading a library, so the bug would only be seen on startup (or maybe switching to news/mail)
#25 Are they going to get rid of the dos window?
Saturday December 18th, 1999 12:06 PM
The dos window is getting pretty annoying. I'm wondering if they are going to get rid of it in M12 Alpha.
#28 dos window
Saturday December 18th, 1999 2:55 PM
from my understanding of earlier MZ postings, the DOS window that belongs to the debugging suite is removed in the pre-M12 installer builds. I believe the zipped, non-installer versions are the ones with the debug suite and DOS window intact.
Am I right about this, folks?
#29 Re: dos window
Saturday December 18th, 1999 3:34 PM
Never tried the installer version.
I did notice a preference to shut it off though (Doesn't seem to work - but its in the debug sectoin)
#30 Re: Are they going to get rid of the dos window?
Saturday December 18th, 1999 4:16 PM
The dos window should stay in the non installer builds in my opinion because it is essential for debugging and testing code.
Even in final, I think, the console should be a prefs option, as it would probably be as useful to future hackers and component developers as well.
#32 Re: Are they going to get rid of the dos window?
Saturday December 18th, 1999 7:05 PM
Typeing "debug:" to see what the program is doing would be interesting.
#34 just remember
Sunday December 19th, 1999 10:03 AM
these are debug builds and the window is for the programmers. mozilla isn't ready for the masses.
#35 Re: just remember
Sunday December 19th, 1999 11:53 AM
#45 Re: Re: just remember
Tuesday December 21st, 1999 12:44 AM
In a release build they remove all the debug code so that the application will be smaller and faster. Since there is no debug code in a release build to generate the messages it wouldn't make much since to have a debug window would it?
#47 debugging code
Thursday December 30th, 1999 6:36 PM
As long as the DOS window remains as a build option (in other words, that code gets compiled into debug versions but not standard end-user versions) then there shouldn't be any problems for future hackers.
#33 Re: Re: Are they going to get rid of the dos windo
Saturday December 18th, 1999 7:30 PM
There should be a way to close the window, or a non-installer version, which does not include the dos window.
#26 Are they going to get rid of the dos window?
Saturday December 18th, 1999 12:07 PM
The dos window is getting pretty annoying. I'm wondering if they are going to get rid of it in M12 Alpha.
#27 non-smooth scrolling via scrollbars?
Saturday December 18th, 1999 2:23 PM
I've noticed that recently (last few weeks) when I use the scrollbars, the window doesn't move smoothly, but rather the area being scrolled to shows up as grey and then is quickly painted. This is pretty annoying when reading a long web page.
I looked in bugzilla and couldn't find any references to this, but didn't want to file a big report if it's something known and being worked on. Anyone care to comment?
#31 Re: non-smooth scrolling via scrollbars?
Saturday December 18th, 1999 4:39 PM
Which OS? They have removed that in the Linux version, but the scrolling still got an annoying rubber-band effect.
#40 Re: Re: non-smooth scrolling via scrollbars?
Monday December 20th, 1999 12:06 PM
It's the Linux version, and yeah, I guess what I'm seeing could be described as "rubber-band effect". I can't find any reference to this on bugzilla -- can you point me to a bug #?
#36 Impressive stability and mailnews question...
Monday December 20th, 1999 7:53 AM
Mozilla has now got to the point where I frequently fire it up to view pages that crash NS4.5! :) In fact, I've done that far more often than I've had to use 4.5 to view pages that crash Moz!
The only thing I haven't tried in Moz is mailnews... a browser crashing is one thing, but I rely on email to do my job and a buggy email client could lose all my messages. Could anyone tell me whether the current (M12-ish) mailnews client is reliable enough to use for daily email? (IMAP, SMTP, Linux, threaded view, with nearly 9000 messages in my largest folder)
#38 Re: Impressive stability and mailnews question...
Monday December 20th, 1999 10:45 AM
Mail and news is stable, but I only use it to read my work account from home. It currently leaves all the messages on the server (Not sure if the option to delete them is functional yet).
It works fine, I can have multiple emails etc... there are still a few bugs, like the incorrect number of emails listed in the total. With news (Only tried it once) I did notice that it downloaded ALL the messages. It didn't give me the option to download 30 or so (Like v4 does)
The one down side to using Mozilla right now to read mail and news is when the registry changes (Its happened a few times but its supposed to be set as of the alpha - so people can develop products for it). And when you have to kill all of the files related to an old daily build... you loose you're email. Well Its stored in the user50 directory but the registry is what points to it... I'm fairly sure with a little hacking around you can get it back.
#39 Leaving Messages on the server pref
Monday December 20th, 1999 11:08 AM
I just read in the newsgroups that the Delete messages from server option has been enabled.
I can see a few people might be in for a surprise :)
#37 is the proxy working yet?
Monday December 20th, 1999 10:31 AM
is the proxy working yet? If not where are the instructions on how to set it up manually?
#42 Re: is the proxy working yet?
Monday December 20th, 1999 1:39 PM
It works for me. I have heard that there are still issues with some proxy authentication or something but proxies have been working and hooked up to the preference UI for some time now.
(posted with mozilla M13 12/20 daily build)
#43 NTLM Authentication?
Monday December 20th, 1999 7:34 PM
Is there any chance Mozilla will support NTLM authentication?
The network people where I work just set up a Microsoft Proxy Server that uses only NTLM authentication requiring IE- effectively wiping out thousands of mostly loyal Navigator users.
They are *not* allowing anonymous access, and they are *not* allowing basic authentication.
I have read some of the past newsgroup posts about it and I realize that NTLM is proprietary and must be reverse engineered to do this.
I wouldn't even expect such a hack to be "officially" supported, as long as it worked well enough.
There seemed to be a general "thumbs down" to NTLM in the newsgroups, but how are we supposed to use a non-Microsoft browser now?
#44 M12 almost here
Monday December 20th, 1999 8:27 PM
Source code for m12 already available at ftp://ftp.mozilla.org/pub/mozilla/releases/m12/
Binaries should appear soon.
#46 M12-binaries available for Solaris 2.7 SPARC
Tuesday December 21st, 1999 6:30 AM
The M12 build for Solaris 2.7 SPARC is ready for download from http://puck.informatik.med.uni-giessen.de/download/mozilla-sparc-sun-solaris2.7-M12.tar.gz Features: - MathML enabled ! - OJI enabled ! - IRC and other extensions, see README...
Please download it ASAP because our Sun cluster is shut down from 22.12.1999 18:00h MET until 2.1.2000 15:00h MET...