Trunk Freezes for 1.2 Alpha TonightTuesday September 3rd, 2002The main development trunk will be frozen at 11:59pm tonight Pacific Daylight Time and will remain frozen until 1.2 Alpha is released. While the freeze is in effect, all checkins to the trunk will require approval from drivers@mozilla.org. Like 1.1 Alpha and 1.1 Beta, 1.2 Alpha will probably be released directly off the trunk with no branching beforehand. The ideal release date is Friday 6th September, though this may change. See the Roadmap for more details about release plans and tinderbox for the current status of the trunk. Hi everybody. Is there some kind of Feature Plan for current/future developments of Mozilla 1.x, x>=2, like there are feature plans (including a 3 state status information) for KDE (3.1, 3.2) ? If there is one, I was too stupid to find it. I think the best you can do is look in bugzilla and follow bonsai (The links are on the right of this page... "Today's checkins" and "Query for bugs"). If you search bugzilla there is stuff that they would like to see (Search for v1.2) but as far as I know nothing is required to release v1.2. > I think the best you can do is look in bugzilla and follow bonsai .. Well, I didn't, I was using pre1.1 builds all the time. But I'd like to catch up with what went into the trunk since the 1.1 branch. Telling me that I should read several weeks of bonsai comments is not the answer. I remember from last year that someone maintained a carpool-landing page where you could at least see the very big checkins. To maintain the attention of the non-daily-bonsai-reading crowd, it'd be good if there was some kind of weblog with substantial checkins (like every few days or so). Previously, one could stay up-to-date with Asa's buildbar, but that's now gone ... :-( Nils There's a link from the main Tinderbox page <http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey> to the landings page. You can also check the vote details at MozillaNews <http://mozillanews.org/> Sigh. The way you write a link in the news is different from in the forums! Here's another try at those links... There's a link from the main Tinderbox page http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey to the landings page. You can also check the vote details at MozillaNews http://mozillanews.org/ " To maintain the attention of the non-daily-bonsai-reading crowd, it'd be good if there was some kind of weblog with substantial checkins (like every few days or so). Previously, one could stay up-to-date with Asa's buildbar, but that's now gone ... :-(" Sounds like the perfect "non-coding" task for a volunteer who likes to follow this kind of information. I've got a nice collection of bookmarks (and someone even wrote for me a very cool web form tool thing that will linkify bug numbers like bugzilla does) and other tools for getting at the interesting changes each day. It turns out that to do this well takes about an hour a day of reading, writing and testing the builds (to see if the bug was actually fixed and how the user can see/test it). I don't have that hour any more but maybe since you're interested in this you could take over and do some daily comments. --Asa Well, the question was not "are people still coding new stuff," but "is there a *plan*?" the answer is yes. is the plan well documented outside of Bugzilla? unfortunately, no. if you wanna know what's going on you're gonna have to dig a little bit. if that answer doesn't satisfy you then maybe you can find someone (or volunteer to do it yourself) to gather all this information from Bugzilla, the landing plan, the website, and the newsgroups and build a nice document that's easy for those not really involved in Mozilla to track. --Asa no delay at all :) keep up the good work guys! After I read this I said "Dear god guys, slow down, I'm still digesting 1.1!" Good to see that development is still going on strong and moving forward.
The developers are still digesting 1.1 as well.... I feel that the milestones are too short and the freezes too frequent; I keep feeling like we're frozen _again_. And if you throw in some commercial releases, the picture looks even bleaker. I very much agree that this deadline was way to short to allow for much meaningful work to occur. I guess I'll let you tell Jag and Darin that the 10% pageload performance gain they made (more gain than was made in the previous 10 months combined) wasn't meaningful. I'll let you explain to Aaron that his type ahead find isn't a meaningful improvement. And while you're at it why don't you tell the bi-di developers that the dozen or so fixes they've landed including making text selection finally work isn't meaningful. Oh, and tell sspitzer that his fix for the most frequently reported mailnews bug ever wasn't meaningful work. And don't forget to tell darin that prefetching LINK tag documents isn't a meaningful change either. And while you're on a roll tell alecf that we didn't really need to handle visited links properly and tell brade that we didn't need that horrible text area scrolls on space bug fixed and tell all the mailnews team that the 100+ bugs they fixed weren't meaningful and tell all the browser and composer developers that the 800+ bugs they fixed weren't meaningful either. And what reasonable person would ever consider 68 hang, crash and topcrash fixes meaningful? 6 dataloss fixes? Definitely meaningless. Over 30 performance improvements? Completely meaningless. Another 20 standards support bugs fixed? Completely without meaning. OK, I know you said "too short to allow for _much_ meaningful work to occur." You're probably not alone in thinking that. But just because some of the Mozilla developers were paying more attention to the 1.0 branch doesn't mean that the trunk stood still. 1.2alpha will have been under heavy development for roughly 5 weeks taking about 1000 fixes. It's time to slow things down for a few days, get something in the hands of our Milestone testers, get some talkback data and start cleaning things up for 1.2beta. But don't fret if you've still got a lot of bugs to fix for this release. We've got 8-10 weeks of development in the cycle before we release Mozilla 1.2final and that should be enough time to get our most important 1.2 issues solved. Hello. With so many "bug" fixes already in place ... is the current code more stable than 1.1 (not that I have problems with 1.1 :-) ) ? Or are there also big new festures which might still be in a "not so stable" state ? Wouldn't it make sense to release 1.1.1 with all or many of the fixes instead or additionally to 1.2alpha ? And I have to ask another thing again: From a user's point of view Mozilla development looks a bit chaotic, with no plan what to do. You (IIRC) wrote in another thread that these things are all "documented" in bugzilla. But I - and I guess most people interested in Mozilla development (besides the developers themselves of course) don't care for bug id's, neither for changelogs which list 1000's of changed files for only one week. Keeping up some "offical" feature list like that of KDE (http://developer.kde.org/development-versions/kde-3.1-features.html) shouldn't be too time consuming, in contrast to the "Kernel Cousins" (http://kt.zork.net/kde/latest.html) which are also very interesting and have laid a lot of people to join the development team. Mozilla is not only a big project, Mozilla is (at least at the moment) potentially used by a lot more people than KDE or Linux, because it's availabe on a lot of platforms. I cannot imagine that in this large user base, it's not possible to find someone who is willing to help out with that. If I hadn't a web project on my own in the works (non IT related) which consumes a big part of my spare time, I would jump in myself... Harald Henkel yes, 1.2alpha will probably be less stable than 1.1final in some areas. In other areas it will be more stable. We fixed lots of high-profile crash bugs but we've added new features and new code that may introduce crashes. That's the point of an "alpha". It probably won't be as stable as 1.1 but it will have new things. With 1.2beta we will respond to crash data we gather in 1.2alpha and so improve on the stability and then we'll repeat, taking crash data from 1.2beta and using it to further stabilize for 1.2final. "From a user's point of view Mozilla development looks a bit chaotic, with no plan what to do." I'm not really sure how to respond to that. Users can see what changed _after_ the release. Developers and testers can see what's going to change _before_ the release. You want people who are working to make Mozilla better to stop doing that work so they can make it more obvious to users what they're working on? I'm all for transparency and we provide a lot with bugzilla, bonsai and lxr but it doesn't seem to me that there is any huge return on time invested to communicate development plans to users. I put a fair amount of time into the What's New and other sections of the release notes so that users can know what they're downloading but I'm not going to put a lot of time into distilling all of the work that's currently goint on or planned to make it digestible for users. Maybe someone else is willing. --Asa Hello. First of all, I want to make clear, that I appreciate greatly, what you and all the other Mozilla developers do. It's simply great work. And I don't intend to burden you with additional workload or keep anyone from what he does/likes best: coding. I guess, that there has been a lot of discussion on the planned release cycle with new x.y versions every 3 month. I just intend to suggest a slightly different one, like that of e.g. KDE: about 6 month for x.y with additional features and about 6 weeks for x.y.z with only bug and security fixes (mainly backported from the x.y+1 development). About "Users can see what changed _after_ the release. Developers and testers can see what's going to change _before_ the release." I know, all the information is available ... somehow. Open source development has a lot of aspects. One is, that there are a lot of people intersted in its ongoing progress. Not only some developers and a realatively small bunch of testers. End of July lwn.net announced that they would have to stop their activity, because they have too much work with that "project" and don't get paid for it. They received immediately hundreds of messages with suggestions how to go on and about >10000$ of donations in a couple of days, because a lot of people love that service. One of the pages there with the most hits seems to be the Kernel Development page and the people reading it are not the kernel hackers or testers, but people who are just interested in reading what's going on. The same is true with the Kernel Cousins for various projects (KDE, Wine, etc.). These are all done not by the developers themselves but people who are just interested in that development and have enough time and interest to do it - and it takes a lot. This is strangely missing for Mozilla (or I have been too blind/stupid to find it). About the "What's New". Do you create this section, starting short before the release , extracting all the relevant information from the change logs and other sources ? Or do you do this on a daily or weekly basis (which I would find more convenient). Then why not publish the results updated daily/weekly ? On the other hand, I still don't understand, if there is some plan, which features should go into the next release, and this is just hidden behind some Bugzilla bugnumber, or if the developers just code what comes into their mind and the "What's New" is really compiled from change logs. Of course the feature plan of my pet example KDE is created similarly, be developers stating what came into their mind they liked to do/code and somebody compiling a list of this. Then the status is roughly followed (planned=red,mostly done=yellow,finished=green). And sometime the featureplan is closed for additions - and a feature plan for the following release is opened. This all is easly accessible through www.kde.org and doesn't have to be searched in a "bug" database. From my point of view, it would be really nice, if Mozilla would have something like that, i.e. some kind soul/s with enough time and interesst could be found doing it (i.e. would step up to do it ;-) ). With kind regards, Harald Henkel Hi Does anyone know if Mozilla Mail lets you set font styles, colors, backgrounds as default? When composing mail, it defaults to Times New Roman and black on white text. But there should be a way to set a different colors as default. I know you can do that with the Composer. Mail seems to take u to a window wheer you can pick the colors, but cant make em the default. Is this an oversight? Personally I hate Times New Roman font, so whenever I email, I have to manually change the font to Verdana and color to grey. Mozilla really needs this capability!! It is tiny things like this that tick of the casual users. Yes Mozilla is moving fassst when it comes to versioning, but I still think there are too many very visible bugs that need to be fixed for Mozilla to be considered a truely complete product. I love Mozilla, but I cannot really give it 10/10. For eg, in Mozilla Mail, the message count is screwed up. My trash had 12 new messages. I deleted all of them. But it still says 11 new messages! This has happened before with my Inbox. It is very random. Somehow it fixed itself the first time. As everyone knows Mozilla seems to suck when it comes to DHTML. It seems to do it very slowly. I think the speed should be vastly improved. Just go take a look at www.dhtmlcentral.com. There are other things like this that can tick of the casual user. We have to think, why would anyone want to use Mozilla? We ned to provide some compelling reasons for people to switch. As it is the slow startup times are a turn off. But that cannot be helped since IE is so tied into Windows. Tabbed browsing, popup killing are great features, but they are already available in Opera, NetCaptor. Mozilla needs some more killer features if it hopes to make people switch. Personally, I have been experimenting Mozilla for a long long time...since M14! But I have becoime a regulat user of Mozilla since 0.9. I have seen some remarkable improvements when it comes to stability in Mozilla. Overall you guys are doing a great job, but you can do better. |