QA got _very_ confused this morning not knowing where to get the latest M3 builds that we rolled off the line last night. some of this confusion was generated by the fact that we are transitioning windows commercial builds from sar to leaf, but it's also complicated by the following reasons: * 5.0x deliver area has unnecessary levels of heirarchy. We are never going to deliver 16bit windows, or 68k mac, or on any macos other than 8.5+. let's flatten the delivery area to something that makes sense. * build directories are different for each platform. Windows uses MarDDHHMM_Milestone, while Mac and UNIX use MarDD_Milestone. Let's get a consistant nameing scheme for the build directories so that anyone can tell which build is which. I propose that we drop the minutes field and deliver into a directory that has the month, then date, and then hour of the build, followed by a milestone identifier. so something like Mar13-10_M3. * no notification e-mail when the builds were complete. QA started rummaging around trying to find the builds for this morning. this is wrong. we should be telling them which builds to grab. this could be done via an automated e-mail from each platform, or minimally, done by hand. we need to get this all straightened out by M4 so QA doesn't waste time downloading the wrong builds or trying to find the right ones when we should be telling them exactly where to go.

setting P1 priority, target milestone M4

This was my bad, i'm reassigning it to me. I'm still trying to track down what happened to the fullcircle build.

fyi we will ship 5.0 Mac tested against OS 8.5, 8.6, perhaps 8.1; we need only one "PPC" folder as the same build is used for all...

cyeh writes: "I propose that we drop the minutes field and deliver into a directory that has the month, then date, and then hour of the build, followed by a milestone identifier. so something like Mar13-10_M3." Would there ever be an situation where two builds for the same platform come out in the same hour? If so, then there could still be mix-ups using the convention mentioned above. I suggest adding an "a" or a "b", etc, after the directory name. Something like: "Mar13-10a_M3" and "Mar13-10b_M3". You really never want to replace the zip file that's ever been posted in any directory. This is what leads to confusion because one person could download foo.zip from a given directory and later in the same hour, another foo.zip gets placed in the same directory. Hard for people to tell which foo.zip they've gotten. Also, I'm finding that the "current" directory can be confusing. Let's say that an email was sent out by release at noon to download the build from the current directory. A person (call him "Joe") reading the email at 1pm downloads the build from the "current" directory. Then later in the same hour, release puts another build (due to some urgent bug fix, I imagine) in current. At 3pm, a person (call him "Sam") reading that email sent at noon downloads a different build than Joe. Joe and Sam talk about a bug that Joe sees, but Sam doesn't see. Is there a way for Joe and Sam to know that they are working on different builds without having to ask the release team? ( Sorry this is so long, but I want to make sure that I give some input to the process you guys decide on. Thanks.

The new build-number hack (which will be formalized and cleaned up later), will let the build be identified while it is being run, so Sam and Joe can compare that before determining that a configuration difference is to blame. http://bugzilla.mozilla.org/show_bug.cgi?id=4004

We've agreed on a date, and i've updated my automation. When everyone has updated their scripts, this can be verified.

reopening, linux and mac don't do YYYY-MM-DD-HH yet.

can we get this done today before the 5 pm spins?

done for linux, assigning to jj.

done for Mac (yesterday). marking resolved fixed.

This is looking good now. Marking Verified.