an attempt to check in a patch and understand contribution better
Jacob Fenwick
1. Gain a deeper understanding of the system of contributing to Django.
2. Checkin a patch that I've attached to a ticket, preferably to all versions of Django.
To achieve goal 1, I plan on learning the process to complete goal 2.
Here is the situation.
I've submitted ticket #10144 ( http://code.djangoproject.com/ticket/10144 ) and included a patch.
My first area of confusion about the process is the timeline in which the Triage stage and the Action Assignment (who the ticket is assigned to) occur . Currently, the ticket has not gone through triage, but I assigned the ticket to myself.
Should I have assigned the ticket to myself? If not, when should it have been assigned? If it should be assigned to me, what do I need to do next?
Another problem that puzzles me. You have to pick a version your ticket should be applied to. What if the patch should be applied to all versions? Do you create a separate ticket for each version of Django?
Jacob
Jacob Kaplan-Moss
> 1. Gain a deeper understanding of the system of contributing to Django.
> 2. Checkin a patch that I've attached to a ticket, preferably to all
> versions of Django.
Great -- we're happy to have the help!
I'm assuming from your specific questions that you've already read the
guide to contributing to Django
(http://docs.djangoproject.com/en/dev/internals/contributing/) and
especially the section about ticket triage
(http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage).
If not, reading through that document is a good idea -- sorry it's so
long, but it does explain how our process works in pretty minute
detail.
I'll answer your specific questions below. First, though, let me
disclaim: I'm about to be exceedingly pedantic, but don't let that put
you off helping. Far better to get a patch up then to be put off by
needing to do everything *perfectly*. Since you're asking about
workflow, though, I'll be as detailed as I can.
Again, please don't take away from this that you have to get all this
stuff perfectly correct; I'm just explaining what the platonic ideal
should be!
> I've submitted ticket #10144 ( http://code.djangoproject.com/ticket/10144 )
> and included a patch.
That looks good; I see you've noticed that a patch against the trunk
instead of just the file is better; thanks for the fix. However,
choosing a better patch name would be nicer. Just "patch.txt" is
useless out of context; something like "10144-import-fix.diff" would
make more sense. Also, the ".diff" naming would make Trac display the
patch with syntax highlighting, which is nice for previews.
A bigger thing, though, is that this is a duplicate of #8193, which
deals with problems in Django's use of __import__ of this form. But I
only know that because I've been looking at __import__ recently; Trac
can make duplicates a bit hard to find. I'll assume you tried and
failed to find a duplicate; no big deal since it'll get marked as a
dup (like I just did) eventually.
But let's assume it wasn't a duplicate, and I'll keep answering your questions:
> Should I have assigned the ticket to myself?
Yes. A ticket should be assigned to the person who's currently working
on the ticket; by assigning it to yourself you indicate that you're
the "point person" for work on this ticket. If the committer has
questions, s/he'll get in touch with the assignee.
> If it should be assigned to me, what do I need to do next?
Next you'll wait for feedback or for a committer
(http://docs.djangoproject.com/en/dev/internals/committers/) to commit
your ticket. For little patches like this one, you should expect it
just to get committed the next time one of us is in the area. At the
moment most of us are focusing on big features for 1.1 Alpha, so you'd
expect not to see it checked in until we start working harder on
bringing the bug count down for 1.1 final.
For bigger patches, you might get feedback/criticism from another
developer. You'd then need to update your patch to fix problems, or
explain why your approach is actually correct.
> Another problem that puzzles me. You have to pick a version your ticket
> should be applied to. What if the patch should be applied to all versions?
> Do you create a separate ticket for each version of Django?
Yeah, that can be a bit obtuse, I agree. The idea is that you'd pick
the *latest* version of Django which has the bug (so "SVN" in your
case). The idea is to let us separate bugs in 1.0 from those fixed in
later versions. In practice, though, we don't much use this field.
For most smaller patches you don't need a patch against multiple
versions -- we use automated merging tools (svnmerge, git) to merge
patches back to the maintenance branches where needed. Testing that
the patch applies cleanly to both branches would make committing a bit
easier, though, so if you *want* to do that you earn bonus points.
Hope I've helped you understand our process more; please let me know
if you have questions.
And thanks again for helping out!
Jacob
Jacob Fenwick
For most smaller patches you don't need a patch against multiple
versions -- we use automated merging tools (svnmerge, git) to merge
patches back to the maintenance branches where needed. Testing that
the patch applies cleanly to both branches would make committing a bit
easier, though, so if you *want* to do that you earn bonus points.
Hope I've helped you understand our process more; please let me knowif you have questions.
And thanks again for helping out!
Jacob
I have four questions:
1. By svnmerge I assume you mean this program: http://www.orcaware.com/svn/wiki/Svnmerge.py
If so, I've never heard of it, thanks for the info.
2. When you say, Testing that the patch applies cleanly to both branches, do you mean /django/trunk and /django/branches/releases/1.0.X?
3. If yes, and I did test against both, would I put both diffs in the included .diff file, or merely note that I tested both?
4. What is a maintenance branch? Is the 1.0.X branch a maintenance branch?
Obviously I don't plan on testing or merging anything at this point since the ticket was a dup, but I thought it was worth lingering in Platonic patch heaven for one last email.
Jacob
Jacob Kaplan-Moss
> 1. By svnmerge I assume you mean this program:
> http://www.orcaware.com/svn/wiki/Svnmerge.py
Yeah, that's right; it takes the gruntwork out of merging between SVN
branches. IIRC it's built into SVN 1.5; I've just not bothered
learning if I need to do anything differently.
> 2. When you say, Testing that the patch applies cleanly to both branches, do
> you mean /django/trunk and /django/branches/releases/1.0.X?
Yeah; at any given time we'll be developing against trunk and
maintaining (at least one) release branch. So right now it's trunk and
1.0.X; once we release 1.1 it'll be trunk, 1.1.X, and 1.0.X (just for
security fixes).
> 3. If yes, and I did test against both, would I put both diffs in the
> included .diff file, or merely note that I tested both?
Most of the time, if a patch fixes a bug in trunk it'll apply clearly
to the release branches, so a single patch is fine. If, for some
reason, it won't apply cleanly then other patches *can* be useful. In
general, though, you can leave it up to us to handle the release
branches: each release has a maintainer (Karen Tracey us the 1.0.X
series maintainer) who helps make sure bug fixes get applied to
maintenance branches correctly.
> 4. What is a maintenance branch? Is the 1.0.X branch a maintenance branch?
See above -- maintenance branches are the ones branches/releases/;
they're where we "maintain" a past release with bug fixes and security
patches. http://docs.djangoproject.com/en/dev/internals/release-process/
has more info on that.
Thanks,
Jacob