Extra Two Weeks Added to 1.3 Beta Cycle
Friday December 27th, 2002
Asa Dotzler has posted an update to the Mozilla 1.3 Beta schedule to netscape.public.mozilla.seamonkey. The target freeze date has been moved back two weeks to Tuesday 22nd January, shifting the ideal release date of Mozilla 1.3 to Thursday 21st February. See the updated Roadmap for more details.
Could we get some more details please. What are the "important changes"? What new features are to expect?
Personally I would like to see the broken bookmark functionality fixed before adding new features
I'm not sure exactly which things Asa has in mind, but most of the stuff that I'm aware of happening is either in the back end of things, or in mail/news... not much going on in the browser UI.
Yes, Mozilla is getting better and better for sure, now even faster with bug 180241 being implemented/tested! Though I still hope that the bookmarks sorting and other bookmark functionality will work in a 1.x release.
"important changes" like:
"fix mispositioning of context menus" "fix crashes in the CSS Loader"
and so forth. We're not talking features here; just fixing of regression fallout from the alpha milestone. And the sudden realization in some quarters that a large fraction of the Mozilla community does not Mozilla work from early/mid-December to early January.
#11 Re: Re: More Details
Saturday December 28th, 2002 10:51 PM
Sudden realization? We had planned to pad beta with 10 days or 2 weeks well before alpha was even released and some key stakeholders were already aware of this. I just suck at getting timely information out.
Yes, sudden realization... imo. this padding should have happened when the roadmap for this was first written, not a month or so ago (which is when the idea started being floated, as best I can recall).
#19 Re: sudden realizations
Sunday December 29th, 2002 2:00 PM
"Yes, sudden realization... imo. this padding should have happened when the roadmap for this was first written, not a month or so ago (which is when the idea started being floated, as best I can recall)."
If this was solely because we expected the holiday period to be slower then maybe you'd be right. If that was the case then we would have included the padding in the original roadmap. But that's not the sole reason we're adding time.
And I did think about it this when we were drawing this roadmap up months ago and decided that there wasn't anything huge scheduled for 1.3 Alpha which meant that having a long and serious cleanup cycle for beta wasn't critical (given that the plan when the roadmap was layed out was that we wouldn't be taking lots of new work or features in a beta cycle).
The reason to extend beta was that a few people petitioned (in the last month or so) to get more into beta than was originally planned. This padding wasn't because we suddenly realized that there weren't going to be a lot of checkins on the last week of Dec and the first week of Jan. That was anticipated and has been each year for the three holiday seasons I've been involved with making milestones happen. The difference this time is that some people actually came and said they wanted to try to get more into beta than the roadmap made time for.
So, yes, there was some "sudden realization" in the last month or so but it wasn't that work would slow down around the holidays. I've been closely involved with shipping the last 27 milestones and I'm more than aware of the normal holiday slowdown. I'm not as new to this game as your post would seem to suggest. I knew about it and given what we knew about the planned work for this cycle, it just wasn't that critical to have a heavy checkin beta cycle. The "sudden realization" was more along the lines of drivers learning that a few contributors needed help getting some more work done in beta in order to meet their deadlines. Had those contributors known 6 months ago that this specific work was going to fall on the cycle that happened during the holidays then maybe we would have padded then but that's not what happened.
#20 Re: Re: sudden realizations
Sunday December 29th, 2002 4:53 PM
I wasn't implying you're new to the game, Asa, and I had not realized that people were trying to get more stuff into beta... From where I stand, I see a largish number of regressions from alpha that need to get addressed and the people who could address them would not have been able to during the originally scheduled beta period... That was what prompted my comments.
#2 How about no sound?
by whiprush <email@example.com>
Saturday December 28th, 2002 3:02 AM
Always good to see the dev team prioritze by the readiness of the release vs. the timeline ... the way it should be. Moz has had strong releases since 1.0.
The anniversary of the 1.0.x branch is getting kinda close, I'm wondering what mozilla.org's plans are post-1.0? Will 1.4/1.5 or one of those milestones be tagged as 2.0 or as the new 'stable' branch? Will there be a 2.0 manifesto like there was for 1.0? or is mozilla.org looking to go to 2.0 in a different way? What are the goals for the next major Mozilla release? Tons of W3C recommendations have been released since 1.0, how do they fit with Mozilla releases, if at all? You guys woke them up with 1.0, surely your waiting for the coup-de-grace for 2.0?
Naturaly, we're all also wondering what the Phoenix team has to say in all of this. If something like a 2.0-type release is what mozilla.org is moving towards then sometime soon would be a good time to announce such a move? I for sure would like to see the same kind of freeze/maturation for a 2.0 branch that was involved with the 1.0.x series; that can only help the trunk.
Looking from the latest Red Hat beta, it's looking like RH is going with 1.2.x as the Mozilla browser to ship with RH 8.1 ... does this mean that the 1.0.x is getting too long in the tooth? Obviously us linux users have been drooling for blizzard's fine work to make it into the other linux distros (if your a linux user and haven't seen gtk2/xft2 mozilla then check it out) - and I'm sure that the Mac, Windows, and linux folks have been waiting for the spam filtering work to make it into mail/news in its full glory as well. Surely the mozilla.org team has been moving to a sweet 1.3 release ... I personally hope that the calendar will make it into 1.3, is this still the plan?
I think I speak for alot of people when I say that the post 1.0 period has been excellent, and maybe its time to stabilize the feature-set after 1.3/1.4 and give the trunk the same attention that it received prior to the 1.0 release?
Mozilla is already the best browser/internet suite/whatever in alot of people's eyes. Lots of people have made Mozilla what it is today, including the volunteers from the OSS community -- mozilla.org, tell us where we're going , so we can test/debug/code, we've had the general idea where to go in the past, but we're there already ... where do we go now?
Where did we mess up? What can the mozilla users do to make it easier on the devs? (Look at the bugzilla and forum posts; yeah, noone wants to be Asa hey?); which platforms needs the most help? Did I bust my GTK2 build because I didn't read some README? Which builds have the most bugs? God, do I have to buy a Mac? I hope not - oh no, mpt hates me.... :) I'm calling Asa out on this since he's always been honest since the beginning ... if you could name 3 areas that mozilla.org needs help in, what would they be? Damnint, call us out .... mozilla.org gave us a bunch of free browsers on linux, get tough ... give us the whole "you wussies, help me!" speech .... either that, or just do the "you wussies!" speech by itself - don't be afraid to piss us off.
Mozilla is only as strong as its's users ... I'm sure most of the forum regular's will raise their hands when it comes to testing/debugging - where is mozilla.org going? and how can we help? Is mpt crazy? Surely _my_ default theme rules. Qute? Never heard of it.... Who's blake? Users? Code Rush? jwz? Nice hair. No. Phoenity rules; where's Mike from mozblog? sspitzer's blog sucks, etc. etc.
(bring on 1.3)
"I personally hope that the calendar will make it into 1.3, is this still the plan? "
Was it ever the plan? Where did you hear this? I would think you would see it in the nightlies right after a major release so it could really be hammered on, but it's not in 1.3a and 1.3b wouldn't seem like the best time to enable it.
code is in the source I pull from cvs, although build instructions must be known only to the Calendar devs
It's in the source, but it's not in the nightlies which are made available for testing purposes. If it's untested they wouldn't distribute it.
For people on windows, calendar is built in the SVG builds (which appear to be built nightly at the moment). Sadly there don't seem to be any linux svg / calendar builds yet.
While this is true, the Windows Gdi+ builds have a set back compared to the ones from Alex (croczilla.org/svg). They only render SVG that is coded into a XHTML that is served as application/xhtml+xml, where as those from Alex can render foo.svg whether it is severed straight or embeded via the object tag and of course the above XHTML files.
Build instructions are here: <http://mozilla.org/projec…alendar/installation.html>
Speaking with my layout developer hat on, layout has not seen any real major arch work since waterson's reflow tree changes right after 1.0... We're hoping to start giving layout some much-needed overhauls soon...
But mustn't there have been work going on in layout, because there are crashes caused by recent regressions in the CSS loader?
Yes, there was a CSS loader rewrite very recently. And the CSS loader is not really part of layout (though tightly tied into it). But that was one of the starting points for the work that should hopefully start happening....
You mention "crashes" and "regressions". I'm only aware of one such (involving mailing yourself a page). Are there others? If so, I'd love to know the bug numbers....
#18 not aware of any more than one
Sunday December 29th, 2002 12:22 PM
Okay, cool. You rule, man.
I know of only the one CSS loader crash that you mention. No others.
I guess I thought there were more crashes because of the general instability I've experienced with Mozilla 1.3 pre-beta. Those are not in the CSS loader, though, I don't think. I shouldn't have implied otherwise.
Can this 'rewrite' of the CSS loader be seen as more CSS properties are now rendered?
If so, is there a doc or file somewhere that says what they are?
No new CSS properties were involved. The rewrite focused on code cleanup and on making the stylesheet ordering code work correctly when script inserts or removes stylesheets.
I'm not sure what doc you're looking for.
Thanks for the information. The 'definitive' list to what Mozilla renders in css1, css2 and css3 as the W3C understands it.
There is no such list.... The closest to it is <http://lxr.mozilla.org/se…ed/public/nsCSSPropList.h>
Besides this one <http://bugzilla.mozilla.org/show_bug.cgi?id=186752> there may be some things that are not working correctly that worked with older builds. <http://www.nvidia.com> menus don't work for example, although I don't know if this is related.