On Mon, Aug 16, 2010 at 12:41 PM, burc...@gmail.com <burc...@gmail.com> wrote: > Hi Russell, > > Thanks for clarifications of the process, but it seems I explained > some things wrong. > > I see some issues have the following problems: > 1) second core developer review takes a year, > 2) reviewers like me who are not core developers don't know if they > will be able to say something new a ticket without reading it, and how > to find such list of tickets. > > When you have not much pairs of eyeballs, it's very important to have > good tickets coverage, and if some tickets don't get reviewed in a > year, it does mean these eyeballs distribution among tickets isn't > good. > > By "curator" I meant core dev team member, who got feedback last time > (or sometimes someone else who can perform core team person job). This > is different from ticket owner (yes, few years ago the ticket owner > was "curator", but now tickets are assigned to patch developer).
This implies that the 'curator' won't ever change; that once a core developer has 'claimed' a ticket, s/he will be the only person to give feedback. Unless a patch is particularly large and messy (which usually means "feature") this isn't the case. A review is a review. Also -- just because I'm able to give feedback on a ticket today doesn't mean I'll be in a position to give feedback tomorrow. > When I mentioned "sorting by time" I meant time of ticket last change, > not ticket creation. I explain it that we currently don't have any way > to find "stale" tickets, which are waiting for some specific action, > but no one knows what exact action. Ok; this is a reasonable suggestion, and it's one that came up the last time Trac was discussed. The biggest impediment here is Trac itself; Trac doesn't share Django's policy on backwards compatibility (they've changed template languages twice in the last two releases), so we're stuck on an old, buggy Trac install that we can't update easily. Jeremy Dunck has been looking into these headaches recently (which, I suspect, is why he raised his voice earlier in this thread). I'll leave it up to Jeremy to give a status update (or call for additional help if he needs it). > I see it like all developers can be divided into 2 categories: > - core dev member, who can make serious decisions, and > - regular developers, who can only check if patch works, if they like > syntax, if there's no any simple logical flaw, or if patch doesn't > work for them, but they can't approve if patch solves the problem is > right way. Usually one want to know if they patch solve the problem > correctly before they polished patch and it got to RFC. Well, it would be nice if only valid, trunk-ready patches made it to RFC, but frankly, I'll take what I can get. *Any* review is better than no review, and if a reviewer is planning to make a habit of contributing, I would hope that regular feedback when bumping an RFC patch back to Accepted would eventually result in less bump-backs, and more committable tickets. > And in this decision making i see the big difference before regular > and core dev developers. > > Basically I want to know if I can do something on ticket without > reading it through. If I can't -- I want to tell that I can't review > ticket and who can. Is the ticket Ready For Checkin? If not, then there is something you can do. What needs to be done will vary from ticket to ticket, but the other ticket flags will generally reveal whether a test is required, or a patch needs review, or documentation is required, etc. Who can review the ticket? Anyone who is willing and able to contribute the time. Decisions are made by those who show up. > So, yes, the additions I propose can be mostly done automatic, with > few exceptions: > - ticket creator marks if issue can be reviewed by any developer or > only core dev (if decision making process is still ongoing). The only > current alternative now is django-dev mailing, I'm not sure if such > mailing should be done every time more core dev clarifications are > needed -- if it is so, I'll go through a couple of my bugs and lots of > other people bugs and start a dozen of threads here right now. I'm not sure I see the value in making the distinction between "can be reviewed by core" or "can be reviewed by the public". A bug is a bug. If someone reports a bug, it's obviously a problem for them. If they provide a patch, presumably it fixes the problem for them. If another developer can reproduce the bug, and can confirm that the patch fixes the bug, that's a significant contribution. If the reviewer can sanity check the patch to make sure it has all the required components, and looks like the right solution to the problem, that's even better. The only nebulous part in this process is whether a patch fixes a bug in the 'right' way. This is really hard to establish, but it's one of those things that comes with experience. It sounds like you might be suggesting that what we need is an intermediate step -- a way to flag that you (as a non-core contributor) have verified that a bug exists, that the patch applies, and that it contains all the relevant bits (tests, docs etc), but that you're not comfortable pushing to RFC because you're not sure if the patch is "correct" to trunk standards. To this I'd say that the solution is to be bold. Pick a ticket where you are moderately confident that you've got the right solution, and push it to RFC. If you're wrong, it will shake out when a core developer looks at it. If I start seeing a lot of RFC comments from a particular contributor, I'll make an effort to look at their work to make sure they're not wasting their time. If you're not comfortable being that bold, say so in the ticket comments; someone else might have more confidence, and if you have gone through the preliminary steps (i.e., verifying that the bug actually exists, that the patch fixes the bug, that the patch applies cleanly, that the patch contains a test and docs as appropriate) then you've provided some very useful feedback for someone else to work with. As for mailing django-dev: Simply flooding the list isn't going to win you any friends. Mailing "I've reviewed ticket XYZ" isn't going to win friends, either. However, if you have a genuine inquiry, django-dev is exactly the right place -- point at a couple of tickets, ask for clarification on the issue that is preventing you from pushing a ticket to RFC (e.g., Is this patch on the right track, or should I be looking higher up for a root cause?). > - regular developer marks if they're done with reviewing issue, and > if the only issues left are decision making ones -- transforming to > DDN again might be considered as an alternative here. DDN means that there is some complex issue that needs resolution at the project level -- something where there are multiple possible options or interpretations. It's not intended as a "I need a core developer to validate this patch" flag -- that's what RFC is for. >>To me, this points to a fairly glaring logical fallacy. If a robot can > fill in new "reviewing" fields based on existing data, then doesn't > that mean that the existing data is sufficient to determine reviewing > state? > Except these two differences marked above, yes, but you can't sort > trac issues based on such derived data. > > ...Or maybe I'm so selfish and tend to complicate things (both is > true), and my small ticket-being-able-to-review / ticket-read ratio > should be ignored as one of the life inconveniences. Complicating things is something I want to avoid, but if there is something that is standing between you and being an effective contributor, then I'd like to get to the root of that issue. I should also point out that I'm not opposed to making changes to Trac. As I noted before, the biggest impediment at the moment is Trac itself; once we've got the basic install up to date, we will be in a better position to add new features. Personally, I have two features that I would like to see. Instead of a adding a whole ticket "review state", I'd like to see the ability to capture, on a per-user basis, the following: * This bug affects me personally * I can verify that the patch on this ticket fixes the problem for me The goal here would be to provide a way to generate reports of: * Bugs that are affecting the most people * Bugs that have patches that multiple people think are good (in the sense that they make the problem go away), but nobody is willing to push to RFC. In both cases, this is just quantification at a database level of the sorts of comments that people are leaving as "+1" right now. IMHO, exposing these +1's as formal Trac reports has the potential to provide a rich source of feedback to reviewers and the core team, providing a hit list of important issues. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
