Updates from November, 2011 Toggle Comment Threads | Keyboard Shortcuts

  • Jane Wells 8:09 pm on November 29, 2011 Permalink | Reply
    Tags:   

    3.3 Status Update 

    Nothing too major has come up since beta 4 last week. Looking at pushing RC1 tomorrow by dev chat time. There are a few bugs and such; check http://core.trac.wordpress.org/report/6 to keep up and help test incoming patches. A bunch of Help tab patches came in, so I’ll be reviewing all the committed text today and doing a patch with any edits for tomorrow’s RC/string freeze push.

    Note to translators: Since we want to get 3.3 launched before the core team meetup if possible (starts Dec 13), that means a little less than two weeks of string freeze. The help tabs may still change before RC tomorrow, but there are two large chunks of text that are new in 3.3 — about.php and index.php (Welcome section) — but have finalized text if you want to get a head start.

     
  • Jane Wells 3:06 pm on November 23, 2011 Permalink | Reply
    Tags:   

    15 10 6 tickets between us and launch. Still need a beta 4 and an RC. The tickets:

    Needs Dev / Bug Wrangler Feedback

    • #19338 Welcome Panel and no JS don’t mix well — Not sure how we missed putting in a no-js version, but we did. Need one. @dkoopersmith was owner of feature, @azaozz has done lots of the no-js stuff in wp, and @joncave made the ticket and wrote a patch. Huddle and work it out. (@jane)
    • #17975 _default_wp_die_handler css referencing logic is fragile and doesn’t always work (@jane)

    Has Patch / Needs Testing

    • #19020 Content Updates for Help Tabs — Tedious. Will finish before before string freeze at RC. Mostly same strings, just moved around a bit. @chexee, @jane and whoever wants to help with some copy paste drudgery patching. (@jane)
    • #19191 Improve admin menu tab navigation — Gotta be keyboard accessible! @dkoopersmith or @azaozz need to check out patch by John Kleinschmidt on ticket. (@jane)
    • #19127 Welcome Panel should be displayed for the first administrator — Panel itself is done, but needs code underneath. @nacin is on this today. (@jane)
    • #19326 jQuery 1.7.1 — They just released this update. There were some issues with 1.7. (@jane)
    • #19292 Not found errors due to sanitization in sanitize_title_with_dashes — Mark’s patch being reviewed. (@jane)
    • #19125 CPT as a submenu item does not get the correct classes when adding new (@jane)
    • #18693 New feature pointers — These are in, but in some browsers aren’t positioning correctly (fixed, [19416]). Also need a little RTL love, see #19335. (@jane) (@nacin)

    Patch Needs Refresh

    • #18880 Back compat for the admin_user_info_links filter (@jane)

    Needs Patch

    • #19088 Accessibility for the admin bar — Screen readers, tabbing, etc. (@jane)
    • #18742 New post-update screen — screen itself is done (translators, might want to get a head start, lots of new strings), but needs code to tell when to show it/to whom. Maybe some RTL love also. @nacin doing the when-to-show code. (@jane)
    • #19320 wp_tiny_mce() cannot call wp_editor(), and other issues — @nacin and @azaozz duking it out on the ticket. (@jane)
    • #19335 Make feature pointers nice for our RTL users (@jane)
    • #18467 Standardize Language on Core Update — @nacin working on it. (@jane)
     
    • Jane Wells 3:42 pm on November 23, 2011 Permalink | Reply

      If it didn’t jump out at you, some help with the accessibility and RTL fixes would great, even if it’s just doing QA the fixes the core team has made.

    • Andrés Sanhueza 3:54 am on November 24, 2011 Permalink | Reply

      Will the 3.2.2 remaining tickets be considered?

    • Denis 12:41 am on November 25, 2011 Permalink | Reply

      Would it be possible to insist, over at onswipe, that they add a “never show this crappy theme” link on WP.com? And if not, would it be possible to disable the thing on this blog, if not on WP.com altogether by default?

      I hate to be bursting on this blog in particular, but it’s the last WP.com I’m still following on my iPad… You guys (as in WP.com) have serious problems ahead if your goal is eye balls, and nonetheless stick with onswipe.

      On a seperate note, there’s a severe bug when writing comments on iOS5 with a 1st gen iPad on this blog. I’ve no idea if it’s iPad or WP related but the comment box’ size toggles between 3 and 10 lines as I’m writing.

      • Jane Wells 1:20 pm on November 25, 2011 Permalink | Reply

        Surely the place for this report would be wp.com support, not the open source project’s core dev team blog. http://en.support.wordpress.com/contact/

      • John Blackbourn 12:08 pm on November 27, 2011 Permalink | Reply

        Of course this is not the place to discuss OnSwipe, but I wholeheartedly agree with Denis. OnSwipe is so unusable it beggars belief that it gets implemented anywhere, let alone on the entire WP.com network.

        @Jane: Would it be possible to disable OnSwipe for iPad for this blog please? It’s under Appearance -> iPad.

  • Jane Wells 1:03 am on November 23, 2011 Permalink | Reply
    Tags:   

    14 tickets.

     
  • Jane Wells 4:13 pm on November 22, 2011 Permalink | Reply
    Tags:   

    It’s that time again in the release cycle where we have to be bad guys to be good guys. We’re past deadline, we’re hitting the holidays, and if we don’t start cutting the cord, 3.3 will hang on until next year. Say it with me: Not again!

    For the people working on the release, most of whom run trunk on their own sites for at least a month or two (if not longer) before each launch, it’s easy to forget that features we had done months ago — flyout menus, drag and drop uploading — are still being hoarded by us (and more recently by the lucky recipients of a merge onto wordpress.com) and are not available on the sites of regular users. While we try to take the time to examine every bug, every fix, and every report of one of those not working, all the stuff that is done and working fine is just sitting there, waiting on the sidelines to be asked to dance by a happy WordPress user who’s still not even at the party.

    It’s time for everyone to join the 3.3 party.

    From the WordPress.org Philosophy page:

    Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release. We aspire to release three major versions a year because through trial and error we’ve found that to be a good balance between getting cool stuff in each release and but not too much that we end up breaking more than we add.

    Good deadlines almost always make you trim something from a release. This is not a bad thing, it’s what they’re supposed to do.

    The route of delaying a release for that one-more-feature is, literally, a rabbit hole. We did that for over a year once, and it wasn’t pleasant for anybody.

    The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.

    So, here’s where we stand: We’ve had some unexpected big bugs (widgets, etc). We’ve had some people get sick. We’ve had some people traveling. Or moving. Or having kids, a job, a family, a life. It happens. We are one week away from our target launch date, and we still need to do beta 4 and an RC cycle. Clearly we will be launching late.

    As of today, we are a steamroller paving the way to 3.3 launch. There are 36 tickets right now. Of those, a few are still time-consuming blockers. Yes, those have to get fixed. If someone can’t write content, that’s a big problem. Pretty much everything else that still needs work will be moved to 3.4-early. Note that “has-patch” is not the same as “has-patch and has been agreed upon as a patch we should include in core.” Patches needing more work… need more work.

    So instead of yelling, “How dare you punt my bug!” please instead focus on how important it is for us to get this release out, and the sooner we do, the sooner we can get back to all the things that got punted or postponed as we start the 3.4 cycle. Hey, we punted our pet projects that weren’t done in time too — language packs, some of the responsive admin stuff, pointers on the new-install tour, etc. No one was spared. (And believe me, I really wanted those pointers.)

    So, countdown to 3.3 should start now. I’d offer a betting pool, but since we could totally rig it, that would be lame. If we can do beta 4 today, RC1 after the US Thanksgiving holiday, we could still release before the core team meetup in mid-Dec. We postponed a release until after the meetup last year, and I wish we hadn’t. So let’s just get this sucker out the door, yeah?

    Shipping is a feature. :)

    And remember, since you run trunk, you’ll get all that 3.4 goodness before you know it!

     
  • Jane Wells 11:27 pm on November 21, 2011 Permalink | Reply
    Tags: swag   

    The miniscule amount of money it raises will help offset the cost of the buttons and stickers we send to WordCamps and meetups. http://wordpress.hellomerch.com

     
    • Basilakis 11:48 pm on November 21, 2011 Permalink | Reply

      With Joomla and virtuemart instead of a WP Plugin! -.-

      • Jane Wells 11:50 pm on November 21, 2011 Permalink | Reply

        If more people would pitch in to help clear out those last stubborn 3.3 bugs, maybe we’d have time to fix the wpswagstore that was built on wp. :)

        • Marko Heijnen 12:17 am on November 22, 2011 Permalink

          If shipping to Europe will be cheaper then, we got a deal and I will try to help :)

        • Bill Dennen 3:35 pm on November 22, 2011 Permalink

          Thanks for putting this store up.

          Would you consider adding a link to the new, temporary store from the old one?

          (I saw the link in my Twitter stream at some point, went to google to look for it later. Got the old store. Dead end.)

          Thanks.

        • Jane Wells 4:50 pm on November 22, 2011 Permalink

          Getting there.

    • Andrew Nacin 8:01 am on November 22, 2011 Permalink | Reply

      While I wasn’t involved in this in any sense, I want to post some sort of an explanation here re: Joomla, so I have somewhere to point people who keep asking.

      The swag store at wpswagstore.com is built on WP. The store for this holiday season is, clearly, not. Typically, merchandise was kept at Pier 38 and mailed by the fine folks at Automattic. Because of Automattic staffing changes and the closing of Pier 38 (all current merchandise is in storage — this is all new stuff), there was a need to re-route orders to a fulfillment center. In order to get this live as quickly as possible, a third-party service was used. Right now, every available core/community developer is working on version 3.3. No one is available to develop (and rapidly develop, at that) the existing swag store to get it up to speed for the current (and who knows, possibly transient) fulfillment situation. This is all just temporary.

      And honestly, it’s not like we chose CafePress. Show a little love for fellow open source projects. :-)

      • Jane Wells 2:37 pm on November 23, 2011 Permalink | Reply

        While those things are true, it’s not the whole story. Let’s face it — WP core team doesn’t build the store, so our attention being on 3.3 is not really a factor. Here’s the real problem, and let this be a rallying cry to ecommerce developers around the world: ecommerce plugins need to be better!

        We launched wpswagstore a while back using wpecommerce. Dan and Jeff at Instinct worked really hard on it (thanks guys) and it hummed along for a while. However, it ultimately wasn’t easy enough to update (product pics not being tied to media library was one big issue that they have since changed), and it didn’t support variations in a way that was working for us. After a year of a love-hate relationship, we decided to try another wp shopping plugin.

        We’d heard good things about PHPurchase (later Cart66), so decided to give it a try. Those guys also were very responsive, fixing bugs we identified, etc. The different structure of setting up pages for each product was more work but also gave us more control, which was nice. However, getting info out of it for shipping was painful, and when they rewrote it, there was no upgrade path besides starting over and re-creating the store, not something we wanted to do. When staffing at Automattic changed, we decided to outsource the fulfillment/shipping instead of doing it ourselves, but the plugin’s reporting was not something that was usable enough in terms of having an outside entity handle our order fulfillment.

        So we decided to try another wp shopping plugin. I asked @johnjamesjacoby to do a review of the major plugins, taking several things into account and ranking them. Based on this analysis, we decided we would try Shopp next. Then @johnjamesjacoby, who was the dev for the store, switched over to working on the Social Team at Automattic (they make Jetpack, HTML emails, etc), and there wasn’t anyone to do the work. So it’s basically waiting until I get that Community Handyman position filled and it can go on their task list. Unless someone wants to volunteer to do the Shopp integration, it will probably be a couple of months before it’s back on WordPress.

        Have to agree with Nacin, though — don’t hate on Joomla! Free software should be supported. That said, the UI on the hello merch store is clunky and I miss our pretty site. Someday it will be back!

        • Gabriel Reguly 7:29 pm on November 23, 2011 Permalink

          Hi Jane,

          I am interested in doing the integration.

          Regards,
          Gabriel

          P.S. Please remove the other comment, I was logged in with a different account :P

    • Gabriel Reguly 4:24 pm on November 22, 2011 Permalink | Reply

      Thanks for the info Nacin.

      I also was wondering why Joomla?, but did not had the spirit of posting it.

      Keep up the work for 3.3.

      Cheers,
      Gabriel

  • Jane Wells 12:45 pm on November 21, 2011 Permalink | Reply
    Tags:   

    45 tickets.

     
  • Jane Wells 4:06 pm on November 20, 2011 Permalink | Reply
    Tags:   

    Also, daily ticket counts time. 55 tickets.

     
  • Jane Wells 3:24 pm on November 20, 2011 Permalink | Reply
    Tags:   

    Still shooting for Beta 4; widgets bug last week threw us for a loop. Sounds like it’s about fixed, so hopefully we can shoot for beta 4 on Monday. If no unexpected blockers crop up, could potentially RC a couple of days later? It seems not very likely that we’ll release by the original target of November 29, but we have a little wiggle room. Core team meetup will be the week of December 12, so if we can get it out by then we’ll be okay.

     
  • Jane Wells 3:39 pm on November 16, 2011 Permalink | Reply
    Tags: ,   

    Time to shoot for beta 4, hopefully last beta on 3.3 cycle. Shooting for beta 4 to happen tomorrow, so today should be full-on milestone scrub day. Dev chat today at 21:00 UTC can be quick status check so as not to derail work. Plan on check-ins tomorrow morning/lunchtime/afternoon/evening depending on timezone to get things moving.

    Agenda:

    • 3.3 task status reports – core team, contributors
    • review blockers
     
  • Andrew Nacin 12:33 am on November 16, 2011 Permalink | Reply
    Tags:   

    I cleared out all tickets in Awaiting Review with a reported version of 3.3. They would normally show up at the top of report 40.

    If anyone wants to help triage the next group — “Defects Awaiting Review, reported against no version” (59 tickets) — here’s some ways to triage a ticket:
    — If it’s an enhancement or feature request, change the ticket type.
    — If it’s a bug that effects a previously released version of WordPress, then change the version field.
    — If there isn’t enough information in the ticket, ask the reporter for more information and add the “reporter-feedback” keyword.

    The main goal here is to identify regressions from 3.2 to 3.3, i.e., things that broke during this development cycle. We typically do a sweep each release not long before RC1, to make sure we didn’t miss a bad bug that was already reported.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Follow

Get every new post delivered to your Inbox.

Join 906 other followers