On Thu, 27 Sep 2007 09:49:32 -0700, "Lloyd Budd" <[EMAIL PROTECTED]> wrote:
> On 9/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > The first rule of any practise, and particularly software development > is every thing has a context, and no approach is universal. > > > I apologize for ruffling feathers, but a very standard best practice > > is that the Golden Master is the last beta, which was the previous > > beta with a couple of bug fixes, which was the previous beta with a > > couple of bug fixes, etc. I just couldn't believe that a change of > > this magnitude was introduced at release time, when all previous > > practices pointed to a professional software development workflow. > > As has been identified a couple of times now, a release candidate with > this change was done a week previous. > > Further, leaving those tables would not improve the situation, only > masks the problem. But the point is valid; an important change like that should've been first, not last, to maximize testing by -not- masking the problem. My plugin also broke (for unrelated reasons) on RC1, when it worked with Beta 1-3 with no changes; I was -very- surprised when I needed to make a change (albeit only to my test harness). What's the bug triage system like (more socially-speaking then technologically)? Is there one? Are bugs (roughly) fixed in order of triaged priority? I notice that 2.3 shipped with 60 bugs remaining -- I would like to think that those 60 are some reasonable resemblance of the "least 60 most important things to fix."* :) Underlying that, I'd also like to think that there's a reason that the tables weren't dropped until RC1 -- do you (or anyone else) happen to know what that reason is? -- Travis * The assumption here being that anything important but too large to get in in time would've been bumped to 2.4 at one of the prior beta checkpoints. _______________________________________________ wp-testers mailing list [email protected] http://lists.automattic.com/mailman/listinfo/wp-testers
