Hi folks --

We have a chronic problem: our new ticket review queue. We get roughly
50 new tickets each week, and we typically don't keep up with this
flow very well. Eventually, someone (Hi, Russ!) takes it on himself to
review the massive backlog, but that's damned painful.

Right now we only have 60 unreviewed tickets in the queue, so now's a
great time to get on top of this problem for once and for all.
Everyone on this list is qualified to help. Please read on to see how,
and the "prize" bit is at the bottom.

For the most part, reviewing these types tickets is an easy process.
Reviewers need to do the following:

* Verify that the reported problem is actually a bug or feature
request. Sometimes people end up at the ticket system when they should
be asking for help on django-users, so they need to be pointed in that
direction. Other times there's not enough information on the ticket to
reproduce it. But most of the time, it's really a bug or feature
request, and a quick comment saying "I can confirm this is a bug"
*really* helps when it comes time to try to fix the problem.

* Make sure the ticket's not a duplicate by searching the tracker for
existing tickets of the same nature.

* Make sure the metadata (ticket type, component, etc.) is correct.

* Move the ticket along the process (probably into into the "accepted"
or "design decision" stages).

It takes me about 5 minutes to review most unreviewed tickets. A few
take longer, but most are pretty quick. Again, this is totally
something anyone here can do. Yeah, you might run into a ticket you
just don't get, and it's fine to skip in and move along. Remember that
there's help in IRC (#django-dev) nearly all the time, though.

Of course, I'd be lying if I said that this was a whole lot of fun, so
here's where the prize bit comes in:

Starting right now, I'm offering a 5-for-1 deal on reviews. If you
have a ticket, patch, or feature request that you'd like *me* to
review, simply review 5 unreviewed tickets then post your review
request on this list with "[5-for-1]" in the subject. I'll prioritize
*your* request the next time I work on Django.

Of course, I encourage other core developers, and anyone else who's
capable, to join me in prioritizing these "5-for-1" requests, but this
isn't a BDFL action or anything -- just my way of trying to keep the
unreviewed queue as low as possible.

Jacob

On Wed, Apr 20, 2011 at 5:25 PM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:

Consider me in on the 5-1 offer.

Alex

--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

Dang it, I forgot the most important part: how to *find* tickets to review!

You can find a link to unreviewed tickets at
http://code.djangoproject.com/wiki/Reports (along with a bunch of
other cool canned queries).

Jacob

On 04/20/2011 04:27 PM, Alex Gaynor wrote:

Same here.

Carl

First of all, this sounds like a nice idea.

It takes me, being a newbie at reviewing tickets, quite some more time.
Would you (or any other core dev / speed reviewer) mind sharing your
workflow? Any scripts to create environments at certain revisions or
something alike? Or to quickly run the relevant tests?

Thanks,

Tino

For what it's worth, "Unreviewed" tickets generally is just making the
decision whether a design decision is needed, or whether the ticket
can be directly accepted as legitimate:

http://docs.djangoproject.com/en/1.3/internals/contributing/#ticket-t...

Many of these tickets will not yet have a patch, and in any case,
someone can validate tickets once they have entered the Accepted
stage; that decision is when the ticket moves to Ready For Checkin.

So first, I mostly review tickets against trunk. If someone's
reporting a bug against 1.2, and I can't reproduce it against trunk,
I'll mark "worksforme" and ask the reporter to reopen if the problem's
against trunk. I'd suggest you start there rather than worry about
multiple versions for now. (When I absolutely have to, I have a bunch
of virtualenvs for different versions, but most of the time reviewing
against trunk is fine).

Also remember that most of the time you just need to make sure the
thing's actually a bug and set the metadata correctly. Most of the
time:

* It's either clearly *not* a bug, in which case I mark it invalid and
politely tell the user to take it to django-users.
* It clearly *is* a bug, and there seems to be a fair bit of
information (steps to reproduce, the traceback, etc.); these I quickly
mark "accepted", fix the metadata, and move on.
* It's a feature request, which means it can be marked "design
decision needed" (and the metadata gets updated).

If you only want to handle tickets that fall into the above that's
*fine* and would already be a huge help.

If you *do* want to try to reproduce the bug, or if there's a patch
you want to try out, here's a few things I do that might help:

* I have a Django project called "scratch" that I've set up to easily
let me test new apps. Basically I just do the following in my settings
file::

    from unipath import FSPath as Path

    BASE = Path(__file__).parent.absolute()

    ...

    INSTALLED_APPS = [
        'django.contrib.auth',
        'django.contrib.contenttypes',
        'django.contrib.sessions',
        'django.contrib.sites',
        'django.contrib.messages',
        'django.contrib.staticfiles',
        'django.contrib.admin',
    ]

    INSTALLED_APPS += [p.name for p in BASE.listdir(filter=Path.isdir)]

This just automatically adds any apps in the current dir to
INSTALLED_APPS, so I can just `./manage.py startapp ticket1234`, write
some code in the app, and then run the server, tests, etc without
messing with the settings file.

(This uses Unipath (`pip install Unipath`) but you could do the same
thing with `os`.)

I use this every time I need to try to reproduce a bug.

* I have a package of test settings on PYTHONPATH. It's just a
directory with different settings files so I can do `runtests.py
--settings=testsettings.sqlite`, `--settings=testsettings.postgres`,
etc.

* I have a little script (https://gist.github.com/933233) called
`runtests` that'll quickly run tests using the above. For example, I
can do `runtests --db=postgres admin_views` to quickly run the admin
view tests.

* I have another little script I use to apply patches
(https://gist.github.com/933116) if I need to test them. It might not
work for anyone else -- I use git-svn, not svn directly -- but take a
look if you like.

Bit of a brain dump, I know, but at least this stuff is out there for
others to use if they like.

Jacob

Hi Tino,

On 04/20/2011 05:14 PM, TiNo wrote:

It takes me longer than 5 mins per ticket, too. I tend to dive in pretty
deep to make sure I'm understanding the full context for a ticket before
accepting it. That said, here are some things I do for convenience; some
of them may be obvious:

- I have virtualenvs for all supported Python versions (2.4-2.7; trunk
has dropped 2.4 support, but I still may need it for backports), and
each one has my development copy of Django already installed in it (with
"pip install -e ." so it's actually using the working tree code and will
see my changes). Combined with "git checkout" this covers "creating
environments at certain revisions".

- I have stock settings modules for running the tests with each database
I have available (MySQL, SQLite3, Postgres), and I actually have these
packaged up with a setup.py and also installed in each Django-dev
virtualenv (with "pip install -e") so they're always on sys.path and
accessible as "testconf.sqlite" etc.

- I have a bare-bones "test project" with a settings module that has the
admin in INSTALLED_APPS and set up in urls.py, and an installed
"testapp" that already has __init__.py, models.py, and admin.py. So for
those cases where I need to try out something manually (often in the
admin), it's just a matter of copy-pasting some things into the
models.py and admin.py, syncing the db, and firing up runserver. And I
actually have this version-controlled so I can commit the "manual test"
setup for a given bug (in a branch named with the ticket number) in case
I need it later for working on the bug.

HTH,

Carl

On 04/20/2011 05:38 PM, Jacob Kaplan-Moss wrote:

So you don't necessarily reproduce it yourself before marking Accepted?

Carl

Mm, it depends. Sometimes I don't need to -- it's clearly a bug, and I
see everything I need to track it down. I generally trust that if the
user could be bothered to write a good, clear bug report that it's
really a bug and I don't need to reproduce it. It's not like moving it
to accepted and *then* finding that it's not really a bug is a
problem. Perfect is the enemy of the good, and all that.

All in all, I'd guess that of the "bug" category tickets I see I need
to take the time to reproduce about half of them. Maybe 2/3rds.

Jacob

Hi,

Thanks to both of you for the write ups. It makes the process a lot more
clear. Will try to put this to action the forthcoming days.

Tino