Make WordPress Core

Tagged: trac Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 6:51 am on October 17, 2012 Permalink
    Tags: trac   

    Trac email issues are fixed 

    Unfortunately, the Trac mailing lists for WordPress Core and BuddyPress were missing many tickets and comments over the last few days. (From about October 15, 12pm ET to about October 17, 2am ET, an hour ago.)

    I OK’d a change to the Trac configs, but forgot about the restrictive mailman rules designed to block spam on these read-only lists. My bad.

    Many of us of course rely on these mailing lists, to the point where if it fails, we miss comments or entire tickets. To explain why you may have gotten some emails, but not all: You would have gotten it directly from Trac (rather than the mailing list) if you were already participating on a ticket.

    I’ve added support for ticket comments directly in the Trac timeline across all Trac instances on wordpress.org. Here are links to days with missing time periods:

    Note that the “From” email for these mailing lists is now noreply@wordpress.org. Rather than something@lists.automattic.com. You may need to adjust Gmail filters as appropriate (there hasn’t been a spam issue on these lists for some time; consider targeting list headers).

    Let me know if you have any lingering issues or questions.

     

  • Andrew Nacin 5:31 pm on September 11, 2012 Permalink
    Tags: trac   

    Marking duplicate tickets on Trac just got a bit smarter and easier. Now, when you mark a ticket a duplicate, you specify the other ticket. A comment will be cross-posted there that references the duplicate, so you don’t have to.

    You can optionally include a comment and any other ticket property changes, as before. If your comment doesn’t include a reference to the ticket, it’ll automatically add it.

    A side effect of how the plugin is written (it’s a modified version of this one) is that no email notification is sent for the “#___ was marked as a duplicate.” This is great because it avoids a double-email (that until now would happen manually). On the other hand, if you consume Trac via your inbox like me, you might expect that the next email is the other ticket, floated to the surface again. I’ll leave it as is for now.

     

  • Andrew Nacin 6:58 pm on September 10, 2012 Permalink
    Tags: trac   

    Trac updates and a design refresh 

    Every few months we make a few improvements to Trac. Given how many hours so many of us spend on there, even the smallest changes can make a big difference. Today, a few new changes were deployed.

    The first thing you’ll notice is a design refresh, from @helenyhou and @ocean90. It cools down the colors a bit and places more of our own mark on it (more WP-like, less Trac-y). They also added responsiveness for mobile devices, and made some adjustments to improve readability. See #18211. If you notice any bugs or quirks, please leave a comment there.

    From @iammattthomas, the WordPress logo is now HiDPI.

    If you’re a bug gardener (i.e. you can change milestones, etc.), you can now change the resolution of a closed ticket. This should make @sergeybiryukov happy — no more re-open to re-close.

    Over the last few weeks I’ve given more than a dozen people bug gardener status. We’d like to empower the people we know and trust to make decisions, while making Trac simpler for others.

    For those who aren’t bug gardeners, we’re trying to make it as easy and streamlined as possible for you to create and contribute to tickets. @bpetty has been studying our workflow and recommending changes. One of those is we’ve hidden the ability to change ownership of a ticket (accept/assign/reviewing). A big issue with ownership is it sometimes discourages others from contributing. I hope this change can free us up to using that field for tracking responsibility and accountability.

    Non-gardeners can also no longer label tickets a “task”. Also, once the Version field is set, a user can’t update the field to a newer version, only an older one. (As @sergeybiryukov says, “version number indicates when the bug was initially introduced/reported.” It’s the earliest known affected version for a bug, or the earliest applicable version for an enhancement.)

    And finally, if you add the “has-patch” keyword to a ticket, “needs-patch” will automatically be removed, and vice versa. (It’s the little things.)

    I hope you enjoy this round of changes. If you have any further suggestions, please share in the comments.

    Bonus. A few weeks ago, we added a ticket graph, inspired by jQuery and using their plugin as a base. I hope to add some more functionality to this in the future. For now, a few of us are using it to study trends and come up with some new ideas for how we can best maintain the ticket queues.

     

  • Andrew Nacin 12:33 am on November 16, 2011 Permalink
    Tags: trac   

    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.

     

  • Andrew Nacin 12:09 am on July 21, 2011 Permalink
    Tags: trac   

    I’ve ported over all of the core Trac modifications to the BuddyPress and bbPress Tracs. In the process, core Trac has been given a fresh coat of paint, and the old Trac logo has been retired.

    Also in the process, I’ve fixed a few bugs:

    • Bad link to the Security FAQ, #17479
    • Ticket fields are too wide in Firefox, #16582
    • Keywords cannot be removed on some browsers (well, Android) thanks to missing href attribute

    Thanks JJJ, MT, and Barry for their assistance.

     

  • Andrew Nacin 9:39 pm on July 7, 2011 Permalink
    Tags: trac   

    There’s a 3.3 milestone on Trac, but please, no tickets (except by committers) until we hold our scope session starting next week.

     

  • Andrew Nacin 11:46 am on June 21, 2011 Permalink
    Tags: trac, triage   

    If anyone has time this week, there are about 100 tickets that need to be reviewed for potential 3.2 issues we missed. The first page of Report 40 lists “Defects Awaiting Review, reported against trunk” and “Defects Awaiting Review, reported against no version.”

    Basically, we’re just looking for bugs to 3.2 features, and regressions. Many of these either need the version numbers dropped (or added) or converted to enhancements. If someone wants to do full triage, ping me or someone in IRC and we’ll arrange milestone adjustments.

    Update: Specifics on how to help.

    • The Version field is for the earliest known version that the ticket affects. For bugs, this would be the version to which it applies or was introduced. All the ones that say “3.2,” if they aren’t new bugs in 3.2, then they should be changed to 3.1 or, for extra credit, earlier.

    • If the ticket is pushing for an enhancement, rather than reporting a bug, then simply change the Type field to “enhancement.” (Rarely “feature request,” never “task.”)

    (Contributors who have participated on Trac before will of course know to adjust keywords, perhaps even adjust milestones and what not. But these are two simple ways to help clean up this report.)

     

  • Andrew Nacin 5:56 pm on April 6, 2011 Permalink
    Tags: , trac   

    The keywords “fixed-major” and “fixed-minor” can be used for tickets that span both a minor and major milestone. A ticket fixed in the major release (and then usually re-opened for minor release consideration) will not show in reports 5 and 6. A ticket fixed in the minor release (and then usually needs more work for a major release) will not show in reports 3 and 4.

    The ticket does need to remain open and set to the minor release milestone, so really it’s just a way for committers get it out of sight, out of mind when appropriate. Eventually a ticket tagged fixed-major will either be backported or not (and closed either way), and a ticket tagged fixed-minor should either be dealt with in a timely fashion, or split into two tickets.

     

    • Peter Westwood 5:57 pm on April 6, 2011 Permalink | Log in to Reply

      I would prefer that we either fix both at the same time (simple backport case) or open a new ticket for the other one (complex backport case)

  • Andrew Nacin 6:29 pm on February 17, 2011 Permalink
    Tags: trac   

    Second round of Trac changes went live earlier:

    • Reporters now automatically receive ticket updates via email.
    • Reporters are asked to add their email to Trac preferences if it isn’t there already. (Next step is pulling this directly from WP.org for all users, but it’ll take a bit of work.)
    • Reporters now see a notice when tickets are marked reporter-feedback. (This is embedded below.)
    • Tickets now need to be previewed before creation. This should cut down on formatting issues.
    • If you try to create a ticket in the Security component, you get a warning reminding you of the proper procedures for reporting suspected vulnerabilities.
    • The license note when uploading an attachment is more prominent and the upload button now explicitly says ‘Agree and Upload.’
     

  • Andrew Nacin 4:30 am on February 6, 2011 Permalink
    Tags: trac   

    As 3.1 winds down and early 3.2 development is likely to start soon, I’m trying to make Trac a bit more usable, ranging from reports to the theme itself.

    I’ve been tinkering with report 40, Tickets Awaiting Review. It now uses the type of ticket, version it was reported against, and keywords, to create five groups of tickets:

    • Defects Awaiting Review, reported against trunk (or no version number specified)
    • Defects Awaiting Review, reported against latest branch
    • Defects Awaiting Review (all other bugs)
    • Enhancements Awaiting Review (includes feature requests)
    • Reporter Feedback / Close (tickets marked for reporter-feedback or close, which overrides the other groups)

    Each group is then sorted in descending order from when the ticket was last modified. Right now the first two groups are the same, but I’ll modify the report once 3.2 development starts.

    Ideally, this will allow us to better track and triage incoming tickets. It also increases the significance of the ‘Version’ field (version it was reported against, but ideally earliest version to which the ticket applies) and removing reporter-feedback when feedback is provided.

    I’ll be working on report 39 (Candidates for 3.2) soon. Suggestions welcome for improvements on both.

     

    • Tomas Kapler 10:44 am on February 8, 2011 Permalink | Log in to Reply

      I have noticed your recommendation to theme and plugins developers to test their themes/plugins. It would be great, if you would ask them to test it with wp-debug set to true. In last few weeks i have tested about 40 plugins, most of them with 4-5 stars and from recommended/most-downloaded group, all of them updated in last months, not old, but more then half of them throws a lot of warning notices as they are using obsolete functions (some of theme obsolete even from wp 2.0 version!), updating not-set variables etc. I have informed their developers, but i can’t do it for 13000 plugins.

      • Andrew Nacin 12:42 pm on February 8, 2011 Permalink | Log in to Reply

        First, thanks so much for testing all of those plugins — that helps a lot, even just to boost my confidence in 3.1. :-) I also appreciate that you’ve informed developers when you’ve seen issues with notices. That’s a great way to contribute back in the community.

        The issue I think is a bit more complicated though. While we try hard to avoid notices, core is not without them. On occasion it isn’t without deprecated behavior (usually an argument we deprecated earlier in the cycle). It’d be a double-standard to enforce notices in plugins. Obviously, you’re not suggesting we enforce it, only that we suggest it.

        But what we’re really looking for right now is just to verify that plugins and themes aren’t flat-out breaking, which could mean that something in 3.1 has regressed and require us to hold up the release. So right now it’s a much different standard we’re looking for. If I emphasized WP_DEBUG on the main blog, users who turn them on would be overwhelmed. Likewise, developers would see so many notices in their own code, that they would be focused on those instead of real bugs or potentially core regressions — or worse, they don’t bother with testing at all, thinking we’re crazy.

        Keep in mind this is coming from one of the larger proponents of WP_DEBUG and cleaning up deprecated usage. We need to be careful of the message we send and when. But heck, I’d fully support an International WP_DEUBG Day maybe at some point in the future. :-) Debug Bar is looking pretty nice, so hopefully once the panels are cleaned up, we can start to really push its use.

        Again, thanks for your thoughts. We really should do everything we can to emphasize debug mode.

        • Rich Pedley 1:30 pm on February 9, 2011 Permalink | Log in to Reply

          can we have WP_DEBUG Day instead…

          Submitted themes have to have tested with WP_DEBUG set, it’s part of the criteria. Plugins don’t go through checks like themes do, and no I’m not suggesting that, but could the plugin they use for themes be adapted for plugins? I’m thinking of testing for deprecated things etc. especially. I know the debug bar has that built in more or less, but that doesn’t cover everything.

        • Andrew Nacin 1:35 pm on February 9, 2011 Permalink | Log in to Reply

          Well, there’s also a fine plugin called Log Deprecated Notices. Eventually, when it is activated along with Debug Bar, it’ll actually take over and pretty up the Deprecated panel.

          You’d be surprised what Debug Bar covers. It handles notices, warnings, and deprecated usage.

        • Rich Pedley 10:26 pm on February 10, 2011 Permalink | Log in to Reply

          nah you’re missing the point. I’m talking about the automated check that is done. Now I know that themes are handled differently, but could an automated check be done on plugins in the SVN repository for deprecated things?

          The more aware plugin developer will be using the debug bar, the log deprecated notices etc etc, but there will be a few that don’t. Or even a few that get missed, having an automated checker at WordPress.org end would help find these, and appropriate action could then be taken – including a temp suspension of that plugin being listed (perhaps)

        • Andrew Nacin 10:29 pm on February 10, 2011 Permalink | Log in to Reply

          We can’t just do a code scan. The issue is that they might be doing a function_exists(), then gracefully degrading to only triggering deprecated functions if necessary — say, to support older versions of WordPress.

        • Rich Pedley 12:55 pm on February 11, 2011 Permalink | Log in to Reply

          True, though I wasn’t sure if plugins were going to go the way themes have done – and only support recent releases, hence the suggestion.

← Older posts

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