We’re getting 3.3 ready for beta. Here’s the gist of how things stand:
- We’re doing daily (almost) bug scrubs in #wordpress-dev to drive down the ticket count.
- Nacin is finishing up WP_Screen and the media button merge.
- Koopersmith is finishing up tabbed help and flyout menu styling.
- Pointers need some styling fixes to be called done enough for 3.3. Pointers will probably be for core only use in 3.3.
- Admin bar needs final walk through and tweaks.
- Welcome box and about this version page need final feedback and tweaks.
- Some of the responsive admin work will be pushed to 3.4 so we have more time to get large screens looking the way we want. Ozz and Jaquith are on it.
- Jane will check all UI/UX feedback tickets and leave comments.
- All task (blessed) tickets should be updated with a comment on current status by the end of the day.
- I will stroke my beard in a diabolical manner while everyone else works.
- Okay, besides that I will be scrubbing bugs, working on more unit tests, and getting coffee for the JS guys.
donnacha of WordSkill 6:37 pm on October 5, 2011 Permalink
Will you be able to get all the diabolical beard stroking into 3.3 or will some of it have to be pushed to 3.4?
Ryan Boren 8:16 pm on October 5, 2011 Permalink
Diabolical beard stroking is a process, not an event.
Bjørn Johansen 1:11 pm on October 13, 2011 Permalink
So until PHP gets thread handling this will block all other processing? Could we at least make it a short process and exectute it once in a while on appropriate places with hooks?
Andrew Nacin 8:31 pm on October 5, 2011 Permalink
Keyword ongoing-project added.
Aaron Jorbin 2:57 am on October 6, 2011 Permalink
This is why we need to be able to like comments in p2
Jane Wells 7:00 pm on October 5, 2011 Permalink
Updated the 3.3 schedule page to reflect revised target date for Beta 1 to be Oct 7 (Friday, two days later than expected but too bad).
Ramoonus 3:07 pm on October 8, 2011 Permalink
delay?
Daniel 9:20 pm on October 6, 2011 Permalink
What about tickets assigned to Awaiting Review milestone? At first I thought it was a good idea, but now it looks like Future Release milestone (846 tickets in AR milestone, 1686 in FR). It will be good to quickly review all these tickets and decide which ones can go to 3.3. In 3.4 we either need to conduct a weekly scrub meetings to review all new tickets, or completely get rid of this milestone and let everyone edit the milestone field (or assign next major release by default if you do not want to let anyone to edit it).
Andrew Nacin 9:35 pm on October 6, 2011 Permalink
Then the issue becomes us punting everything to Future when we’re ready to go to beta, and they further rot. It’s a mess. Locking down the milestones did help. It keeps scope manageable, allows trusted core contributors to make decisions. There are a number of non-committers who have access to these fields.
Yes, sometimes, some tickets fall through. There will always be bugs. But certainly not many get flat-out missed.
You’re right, both buckets need a serious cleaning. We should probably do this systematically after we hit RC and branch 3.3 off. Then trunk can become early development and we can scrub in the month of December.
If anyone sees anything in Awaiting Review now that needs 3.3 attention (non-enhancements), feel free to leave a comment to that effect, and someone will promote it.
John Levandowski 2:44 am on October 7, 2011 Permalink
I have 2 tickets that I created with patches that I’d like to see included in 3.3:
http://core.trac.wordpress.org/ticket/18649
http://core.trac.wordpress.org/ticket/18650
Jane Wells 12:25 pm on October 7, 2011 Permalink
Have left UI feedback on:
I’ll circle back on these in the next batch because I have to go load a moving truck at my mom’s:
@azaozz: Can you pop in on these?
@dkoopersmith: You’re up.
@developersmind: What up, dawg?
@nacin: Please hit these or remove yourself as owner so someone else won’t feel like they’re stepping on your toes: