On Wednesday 31 May 2006 15:42, Adrian Holovaty wrote:
> On 5/31/06, Jay Parlar <[EMAIL PROTECTED]> wrote:
> > Just wondering what the procedure is for getting a patch accepted?
> > I submitted a patch (http://code.djangoproject.com/ticket/1994) a
> > week ago, and have had no feedback on it so far.
> >
> > Is there some kind of monthly IRC meetup where pending patches are
> > discussed? Or is it just when the core developers have free time
> > for it?
>
> It's the latter. Me, I generally have one afternoon a week in which I
> focus on clearing out patches and tickets, plus weeknights as my
> schedule allows. I'm pretty sure Jacob works the same way, although
> he has been *super* busy traveling and moving lately. Ideas for
> improving this system would be much appreciated!
As a moderately experienced django hacker, I'm happy to help out with
this stuff (I have already been doing a bit, if in a rather haphazard
way), and I've had a think about it and detailed some ideas below.
Problem
=======
The basic problem, as I see it, is:
People have no idea for a long time whether their patch is likely to be
accepted at all, and if it is, when.
This is important because people need to know whether to use another
work around or continue with their patch. Also the wait-and-see game
can drag on people's patience -- there is a currently a ticket with a
patch that was opened 11 months ago, and it's still waiting for some
kind of review. (Of course don't think for a moment that this is a
criticism of Adrian and Jacob -- it is just what has happened with
limited resources and a lot of demand, but it nonetheless can be
frustrating for contributors, as already noted).
Principles
==========
The solutions to this problem have to be:
- low maintenance
- opt in, to allow experienced django developers to
contribute as much or as little as they want, as their
experience and time allows.
- rigorous -- patches shouldn't wait months with no feedback
while others get applied immediately, there should be some
system to ensure everything gets reviewed.
- actually remove work-load from Adrian and Jacob, including the
time spent looking through bug lists etc.
- integrate with existing stuff -- no extra mailing lists
or websites please.
Suggestions
===========
I think it would be good to aim to add an initial comment to each
patch within N days (where Adrian and Jacob should decide the value of
N!). I would suggest that some of the experienced Django hackers should
be allowed to do this initial review (especially for obvious
WONTFIXes). I'll call these developers 'exp devs', Adrian and Jacob
and probably other commiters 'core devs', and both groups together 'all
devs'.
A number of stock answers could be helpful. They would be
different for new feature patches and bug patches, and might be
something like below:
For bugs:
- [core devs] patch looks OK, I aim to apply within N days/week
- [all devs] please add a test that supports the bug [obviously not
always feasible]
- [all devs] needs more review, I aim to do this in N days/weeks
- [exp devs] patch tests OK, I suggest to the core devs that this patch
(or my tidied up version) is applied immediately.
For new features:
- [core devs] this patch is almost certain to be accepted, I aim to
apply it within N days/weeks.
- [all devs] this patch is likely to be accepted at some point, I aim
to review again in N days/weeks.
- [all devs] this is interesting, but will have to wait for Django 1.1
- [all devs] this patch is unlikely to be accepted, as I don't see
that the need is common enough, or it can be implemented in other ways
(featuritis), unless you can convince me otherwise.
- [all devs] clean up your patch, add some documentation etc and I'll
have another look.
- [exp devs] - patch seems Good and Right, I suggest to the core devs
that this patch (or my tidied up version) is applied immediately.
For each case where there is an aim to review or apply, you could add a
todo-[yourname] to the Trac keywords, so you could search for these (I
guess this is what the 'assigned' field is for, but it just defaults
to a component owner, and most of them are 'Adrian' at the moment, far
more than I suppose he can deal with, so 'assigned = Adrian' is not
very useful for him. I think assigned here really means 'I will look
at this and decide what to do if no-one else does'. We need a way to
distinguish between the 'I will definitely do this' and 'this has just
been assigned to me by Trac' situations).
There is the issue of which tickets to handle -- I am a big culprit
here, as my procedure is totally random -- if I happen to notice
something on django-updates I'll have a look. Maybe we need to be
pedantic about using http://code.djangoproject.com/report/12 and
starting from the bottom.
The problem with that report is that it won't distinguish between
tickets where you are waiting for the ticket owner to get back to you
(fix their patch or whatever), tickets that are awaiting some
attention, and tickets that are on your todo list. I think we need
some more specialised reports:
1) active tickets with patches that are awaiting attention from the
django devs i.e. they are brand new, or the owner has uploaded a new
patch. This report is the one that really needs to be kept small,
to avoid frustrations of contributors.
2) tickets that are on my todo list.
3) for the core devs -- tickets that other devs have suggested can
be applied immediately.
The rest (i.e. where the ticket owner needs to clean up his patch etc)
can be ignored -- you don't need a report, except maybe to close them
after 6 months, on the assumption that the owner doesn't care any
more.
Implementation
==============
To implement this, new patches need to appear on (1), and you need a
way to signal a ticket should be removed from (1). I guess you could
do this with keywords of some kind (e.g. 'needswork') perhaps
requiring the ticket owner to change the keyword back when they're
done (remove 'needswork') (alternatively you could just close WONTFIX
until the patch is improved -- a bit drastic perhaps). A ticket
should also be removed from (1) when a developer volunteers to handle
it, e.g. by adding 'todo-[myname]' or 'todo [myname]' to the
keywords. You would also need a keyword such as 'suggestapply' for
the non-core devs to suggest to the core devs that patches are
applied. This would need to be accompanied by a comment from the
developer, who would have to be someone with a Trac login so that Joe
Django-User doesn't try to be sneaky.
There are details to be worked out here, and there may be better
ways of implementing it, but what do people think?
There would also be the responsibility on everyone who 'adopts' a
ticket to 'unadopt' it if they realise they won't be able to look at
it in the time they've said.
It looks like Trac will be able to support reports like these -- I'm
happy to play around creating reports, but I'll need someone else to
add them to the default list.
Phew, that was long, sorry about that!
Regards,
Luke
--
"Trouble: Luck can't last a lifetime, unless you die young."
(despair.com)
Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
