Re: Checking if my patch would be a useful contribution
On Sat, Aug 14, 2010 at 6:12 PM, Swizec Teller wrote: > Hi all, > > brand new django contributor here, been using it so much I reckon it's > about time I started giving back :) > > Anyhow, I'm using Django primarily to develop RESTful API's for web > services. This of course means a lot of JSON is getting passed around > in GET/POST requests so I wrote a simple form field JSONField that > handles json validation and deserialisation because it was getting > annoying having to do it by hand all the time. > > My question is: Is this something that would be useful to upstream? My immediate reaction is no, because I can't say I've come across many REST APIs that use JSON submitted in POST data in form-encoded format (which I presume is the use case here). When I see REST APIs using JSON, the POST is usually encoded application/json, and the whole packet is JSON; any 'field-based' logic is handled by top-level keys in the JSON. Django-piston is an example of a framework that does this sort of processing. I would suggest that this may be better suited to a utility library; if it turns out this utility library gets lots of use, we can consider it for inclusion in trunk. > Oh and I also wrote a decorator for validating forms, makes for > cleaner code than how current examples in the documentation handle > that. Should I contribute that too? We're open to any suggestions, but we need to see what's being proposed. 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.
Re: Trac issues review
On Mon, Aug 16, 2010 at 12:41 PM, 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
Re: dev process [was: #11834: colorized debug page]
On Mon, Aug 16, 2010 at 12:23 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > My apologies -- I haven't watched the video for a while, so I forgot > that detail. I'm not sure adopting that policy would help Django, > though; we have enough of a bottleneck with committers without > exacerbating the problem. Sure, I just happened to be watching it right then, so I thought I'd put it in textual form where people can see it without spending 30 minutes listing to the talk. :-) I'm certainly not arguing that we should adopt such a policy, but it is a neat idea. Like you've been saying, Django trunk does a pretty good job of staying stable as it is and things seem to get fairly well tested on an ongoing basis, so I'm not sure it's an issue. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- 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.
Re: Trac issues review
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). 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. 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. 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. 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. - 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. On Mon, Aug 16, 2010 at 8:28 AM, Russell Keith-Magee wrote: >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. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
Re: dev process [was: #11834: colorized debug page]
On Mon, Aug 16, 2010 at 10:50 AM, Tobias McNulty wrote: > On Sun, Aug 15, 2010 at 10:31 PM, Russell Keith-Magee > wrote: >> >> On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli >> wrote: >> > - punish dev's who don't fix their bugs quickly after api lock >> > >> > (The presentation lacks specifics on the last point. ;) >> >> Which is a big omission. When you're not paying anyone, and you >> already have a problem getting contributions, you have limited options >> for punishment. I'd be very interested to hear what constitutes >> "punishment" in this approach. > > For the record, it is mentioned. The punishment they tried for a few > releases was denying commits from the developers who did not do their fair > share of testing for 2 weeks after the tree was unlocked for everyone else. My apologies -- I haven't watched the video for a while, so I forgot that detail. I'm not sure adopting that policy would help Django, though; we have enough of a bottleneck with committers without exacerbating the problem. 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.
Re: dev process [was: #11834: colorized debug page]
On Mon, Aug 16, 2010 at 11:08 AM, Mark Bucciarelli wrote: > On Mon, Aug 16, 2010 at 10:31:11AM +0800, Russell Keith-Magee wrote: >> On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli wrote: >> >> > ?- random api lock (people tend towards complacency) >> >> I'm not entirely certain I understand this point -- or, at least, >> how it would apply to Django. >> > > So the interface between backend and object model is one. I suppose > there is an equivalent interface on the template side. > > One example that tripped me up: in 1.2, the signature of > BaseDatabaseWrapper __init__() changed. > > In 1.1, I had > > def __init__(self, settings_dict): > > and in 1.2 I needed > > def __init__(self, *args, **kwargs): > >> >> Our APIs are always locked, since we don't allow backwards incompatible >> API changes. >> > > My 1.1 version must have been wrong then. A point of clarification on my part: we don't allow backwards incompatible API changes in APIs declared as stable. The API for database backends isn't currently on that list [1]. [1] http://docs.djangoproject.com/en/1.2/misc/api-stability/ Whether we should promote the backed interface to a stable interface is a separate issue, but certainly one worth discussion (especially given that there are a number of external database backends emerging in the community). >> > Also, hackathons are a great idea. ?A room full of core developers can >> > get a hell of a lot done in a week. >> >> You won't get any argument from me on this one. >> > > I wonder if you ran a really targetting fund-raising campaign how much > would come in. I know when the use is specific, it's easier to raise > money. Sounds like if you raised $12k it would get you pretty close. An interesting idea, and one where the Django Foundation could play a big role. However, this doesn't address the 'getting a week off work' issue 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.
Re: dev process [was: #11834: colorized debug page]
On Mon, Aug 16, 2010 at 10:31:11AM +0800, Russell Keith-Magee wrote: > On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli wrote: > > > ?- random api lock (people tend towards complacency) > > I'm not entirely certain I understand this point -- or, at least, > how it would apply to Django. > So the interface between backend and object model is one. I suppose there is an equivalent interface on the template side. One example that tripped me up: in 1.2, the signature of BaseDatabaseWrapper __init__() changed. In 1.1, I had def __init__(self, settings_dict): and in 1.2 I needed def __init__(self, *args, **kwargs): > > Our APIs are always locked, since we don't allow backwards incompatible > API changes. > My 1.1 version must have been wrong then. > > > ?- punish dev's who don't fix their bugs quickly after api lock > > > > (The presentation lacks specifics on the last point. ;) > > Which is a big omission. > I'm not a dev there, so I don't know. I'm a regular lurker on the mailing lists though, so it either happens off-list or on-list but very infrequently. > > > Also, hackathons are a great idea. ?A room full of core developers can > > get a hell of a lot done in a week. > > You won't get any argument from me on this one. > I wonder if you ran a really targetting fund-raising campaign how much would come in. I know when the use is specific, it's easier to raise money. Sounds like if you raised $12k it would get you pretty close. m -- 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.
Re: dev process [was: #11834: colorized debug page]
On Sun, Aug 15, 2010 at 10:31 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli > wrote: > > - punish dev's who don't fix their bugs quickly after api lock > > > > (The presentation lacks specifics on the last point. ;) > > Which is a big omission. When you're not paying anyone, and you > already have a problem getting contributions, you have limited options > for punishment. I'd be very interested to hear what constitutes > "punishment" in this approach. For the record, it is mentioned. The punishment they tried for a few releases was denying commits from the developers who did not do their fair share of testing for 2 weeks after the tree was unlocked for everyone else. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- 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.
Re: dev process [was: #11834: colorized debug page]
On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli wrote: > On Sat, Aug 14, 2010 at 03:03:27PM +0800, Russell Keith-Magee wrote: >> >> If you have suggestions on how we can improve Django's development >> process and address these issues, we're happy to hear them. >> > > You may find this interesting: > > http://openbsd.org/papers/asiabsdcon2009-release_engineering/ > > (There's also a video of the presentation on YouTube.) I've seen the video before; I didn't know the slide deck was available. Thanks for the link. My take on this is that we're reasonably close to OpenBSD's development process. The only significant difference is that we have the 'feature discussion' period where very little gets done on the tree, and major features are committed once that discussion period has lapsed. If you look at the 1.2 cycle, most of the major features were committed in December, just prior to the alpha release. If you dropped the 'feature discussion' period from the 1.2 timeline, you would end up with a development cycle that matches fairly closely to OpenBSD's. We have the feature development phase for a very good reason -- we have extremely limited resources (based on the charts in that slide deck, *much* lower than OpenBSD), and we want to focus those resources. If we continued to discuss new features while we were trying to get a release out the door, it becomes even harder to meet deadlines, because resources that would be dedicated to finding and fixing bugs (both core team resources and general community resources) are diverted into developing new code. > Tenets: > > - all development on trunk (no $ for QA team in free software) We already do this. > - daily snapshots (eat your own dogfood) In an era where you can pip install from a git/hg/svn repository, this isn't as important as it once was (or as important as it is for system software like OpenBSD). However, I agree that it would be good to automate this process somewhat (if only because we have a very low bus factor when it comes to release management). > - random api lock (people tend towards complacency) I'm not entirely certain I understand this point -- or, at least, how it would apply to Django. Our APIs are always locked, since we don't allow backwards incompatible API changes. Major new features don't get added to trunk until we're happy with their API, so new features aren't subject to API changes, either. > - punish dev's who don't fix their bugs quickly after api lock > > (The presentation lacks specifics on the last point. ;) Which is a big omission. When you're not paying anyone, and you already have a problem getting contributions, you have limited options for punishment. I'd be very interested to hear what constitutes "punishment" in this approach. > Also, hackathons are a great idea. A room full of core developers can > get a hell of a lot done in a week. You won't get any argument from me on this one. The complication is geography, and the resultant cost. I'm based in Western Australia, so it costs around $3000 to get me in a room with the other core developers somewhere in the US. That number is slightly less for Malcolm, because he's based on the east coast of Australia. Luke and Jannis both have to cross the Atlantic. And this completely avoids the question of how we find the time out of our work schedules to contribute a week of development effort. Any suggestions on how to overcome these limitations will be gratefully received:-) 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.
dev process [was: #11834: colorized debug page]
On Sat, Aug 14, 2010 at 03:03:27PM +0800, Russell Keith-Magee wrote: > > If you have suggestions on how we can improve Django's development > process and address these issues, we're happy to hear them. > You may find this interesting: http://openbsd.org/papers/asiabsdcon2009-release_engineering/ (There's also a video of the presentation on YouTube.) Tenets: - all development on trunk (no $ for QA team in free software) - daily snapshots (eat your own dogfood) - random api lock (people tend towards complacency) - punish dev's who don't fix their bugs quickly after api lock (The presentation lacks specifics on the last point. ;) Also, hackathons are a great idea. A room full of core developers can get a hell of a lot done in a week. m -- 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.
Re: Trac issues review
On Sun, Aug 15, 2010 at 3:03 PM, burc...@gmail.com wrote: > Hi Russell, > > On Sat, Aug 14, 2010 at 2:03 PM, Russell Keith-Magee > wrote: >> On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com wrote: >>> I had few useful thoughts about changing the way Django development >>> contributions gets accepted and committed -- but all I get from this >>> mailing list that all attempts to improve any process is just a waste >>> of time. >> >> That's not entirely fair. >> >> We're acutely aware of the fact that there is a backlog of tickets >> that need attention. We're also aware that many people upload patches, >> but then don't get any feedback on them. We want to improve this in >> any way we can. >> >> If you have suggestions on how we can improve Django's development >> process and address these issues, we're happy to hear them. >> >> However, that doesn't mean we're going to immediately implement a >> suggestion just because it's been made. I don't know which suggestion >> in particular you're referring to, but if you've made a suggestion and >> we haven't acted on it, then I would suggest to you that this is >> because we (the core team) didn't agree that your idea was as useful >> or practical as you think it was. >> >> If you have a suggestion, please make it. We're listening. > > Ok. I think the reviewing workflow should be improved in the way core > developers, triagers and patch developers should get a list of tickets > to work on. Please correct me if I'm wrong, but I don't see any > mechanism that will allow you: > a) to find issues that needs a review (not some issues, but all issues > ordered by importance or date sent to reviewing) http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=%211&has_patch=1&order=priority&stage=Accepted That is -- all the tickets that have been accepted and have a patch that is currently marked as "ok". There's a separate query that also requires attention: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&order=priority&stage=Unreviewed This is the triage task, and it's just as important as writing/reviewing patches. Ordering by 'importance' isn't something we support. Historically, we did, and it consistently proved to be almost useless as a measure of anything. Everyone thinks that the problem they submit is very important, so having importance as an open field in Trac doesn't yield useful data. A more helpful measure of 'importance' is the vitality of the discussion under the ticket; a ticket with lots of interest will almost always have a large number of comments, usually a couple of which that say "why hasn't this been merged yet?". The other useful measure is the number of times an issue is re-reported. We don't have a good measure of this, AFAIK. Ordering by date isn't something that we expose particularly well either, but we have an analog -- the ticket number. Tickets are allocated sequentially, so ticket 1234 was logged before 2345. It doesn't take too long working with Trac to work out that a ticket with a number in the 8000 range is about 2 years old; 14000 is less than a month old. > b) to mark issue as reviewed. This one we definitely support. Tickets that have been reviewed and are good: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&order=priority&stage=Ready+for+checkin Tickets with a negative review: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=1&order=priority > c) to mark someone (core dev/someone else) as a curator on an issue, > so core team doesn't repeat themselves reviewing each bug multiple > times when it's not required. > The problem issues don't get attention is that no one usually know > they need their attention. > Bug states don't help a lot: they mark the maturity of solution but > not who's move is now. > And current process from my point of view is a Monte-Carlo issue > picking. It's not broken -- speed is almost the same (cause it's the > speed of commit process), but absolutely no feeling of control. I'm not sure exactly what you're concerned about here. The "curator" of an issue is the owner. If you claim a ticket, you are curating it. As for the problem of multiple reviewing: Allow me to assure you that for me personally, 'double reviewing' of tickets isn't a problem I face. I have three working lists for tickets: * The list of tickets marked against milestone 1.3 * The list of tickets marked Ready For Checkin * My personal list of tickets that I've flagged as interesting. This usually means that something in the report caught my attention, or because someone on django-dev has made a polite request for review. If I review a ticket on the RFC list and it isn't RFC, it gets bumped back to Accepted (with any other flag changes that are required) If a ticket is on either of the other two working lists, I work on them until they're finished (which means the
Re: proposal: abstract file upload/download handling
On Sat, Aug 14, 2010 at 1:45 PM, Waldemar Kornewald wrote: > On Thu, Jul 22, 2010 at 4:30 AM, Russell Keith-Magee > wrote: >> I accept the need for this, but this seems like a bit of a wart. This >> method wouldn't be required at all if the Form took a request >> argument. This isn't an unusual requirement, either -- perhaps we >> should introduce a RequestForm/RequestModelForm that formalizes the >> availability of the request object during form processing. > > OK, I've now added a Request(Model)Form. The tag is based on > ., so you don't have to manually specify > it. FileField takes an optional parameter to override this. Forms > currently only allow to set the tag by subclassing. Not sure if this > is sufficient. > http://code.djangoproject.com/attachment/ticket/13960/filetransfers.3.diff > Now I've finished admin UI support for the proposed API: http://code.djangoproject.com/attachment/ticket/13960/filetransfers.4.diff If you want to see a more practical example, the following demonstrates an async upload process (like with S3 or App Engine): http://bitbucket.org/wkornewald/upload-sample-trunk-filetransfers The same async upload process is used in the admin UI. If you submit a file from within the admin UI the file first gets sent to a view at /upload and then the request gets forwarded to the actual admin view. Also, the backend changes the file download URLs (even in the admin UI) to point to the download view at /download. BTW, if you're too busy/lazy to apply the patch you can just clone my Django development branch: http://bitbucket.org/wkornewald/django-trunk-filetransfers Bye, Waldemar Kornewald -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- 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.
Re: Trac issues review
On Sun, Aug 15, 2010 at 11:33 AM, burc...@gmail.com wrote: > Hi Jeremy, > ... >> >> Sorry, I've missed some context here -- can someone point me to the >> beginning of this thread? > > Thread "#11834: colorized debug page. Assigned to buriy" ( > http://groups.google.com/group/django-developers/browse_thread/thread/bd43e2e040a17784 > ) is the beginning. > Thanks, got it. -- 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.
Re: Trac issues review
On 15 August 2010 17:09, Jeremy Dunck wrote: > On Sun, Aug 15, 2010 at 2:03 AM, burc...@gmail.com > wrote: > > Hi Russell, > > > > On Sat, Aug 14, 2010 at 2:03 PM, Russell Keith-Magee > > wrote: > >> On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com > wrote: > >>> I had few useful thoughts about changing the way Django development > >>> contributions gets accepted and committed -- but all I get from this > >>> mailing list that all attempts to improve any process is just a waste > >>> of time. > >> > >> That's not entirely fair. > ... > > Sorry, I've missed some context here -- can someone point me to the > beginning of this thread? It was previously titled "#11834: colorized debug page. Assigned to buriy" http://groups.google.com/group/django-developers/browse_thread/thread/bd43e2e040a17784 -- 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.
Re: Trac issues review
Hi Jeremy, On Sun, Aug 15, 2010 at 11:09 PM, Jeremy Dunck wrote: > On Sun, Aug 15, 2010 at 2:03 AM, burc...@gmail.com wrote: >> Hi Russell, >> >> On Sat, Aug 14, 2010 at 2:03 PM, Russell Keith-Magee >> wrote: >>> On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com >>> wrote: I had few useful thoughts about changing the way Django development contributions gets accepted and committed -- but all I get from this mailing list that all attempts to improve any process is just a waste of time. >>> >>> That's not entirely fair. > ... > > Sorry, I've missed some context here -- can someone point me to the > beginning of this thread? Thread "#11834: colorized debug page. Assigned to buriy" ( http://groups.google.com/group/django-developers/browse_thread/thread/bd43e2e040a17784 ) is the beginning. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
Re: Trac issues review
On Sun, Aug 15, 2010 at 2:03 AM, burc...@gmail.com wrote: > Hi Russell, > > On Sat, Aug 14, 2010 at 2:03 PM, Russell Keith-Magee > wrote: >> On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com wrote: >>> I had few useful thoughts about changing the way Django development >>> contributions gets accepted and committed -- but all I get from this >>> mailing list that all attempts to improve any process is just a waste >>> of time. >> >> That's not entirely fair. ... Sorry, I've missed some context here -- can someone point me to the beginning of this thread? -- 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.
Trac issues review
Hi Russell, On Sat, Aug 14, 2010 at 2:03 PM, Russell Keith-Magee wrote: > On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com wrote: >> I had few useful thoughts about changing the way Django development >> contributions gets accepted and committed -- but all I get from this >> mailing list that all attempts to improve any process is just a waste >> of time. > > That's not entirely fair. > > We're acutely aware of the fact that there is a backlog of tickets > that need attention. We're also aware that many people upload patches, > but then don't get any feedback on them. We want to improve this in > any way we can. > > If you have suggestions on how we can improve Django's development > process and address these issues, we're happy to hear them. > > However, that doesn't mean we're going to immediately implement a > suggestion just because it's been made. I don't know which suggestion > in particular you're referring to, but if you've made a suggestion and > we haven't acted on it, then I would suggest to you that this is > because we (the core team) didn't agree that your idea was as useful > or practical as you think it was. > > If you have a suggestion, please make it. We're listening. Ok. I think the reviewing workflow should be improved in the way core developers, triagers and patch developers should get a list of tickets to work on. Please correct me if I'm wrong, but I don't see any mechanism that will allow you: a) to find issues that needs a review (not some issues, but all issues ordered by importance or date sent to reviewing) b) to mark issue as reviewed. c) to mark someone (core dev/someone else) as a curator on an issue, so core team doesn't repeat themselves reviewing each bug multiple times when it's not required. The problem issues don't get attention is that no one usually know they need their attention. Bug states don't help a lot: they mark the maturity of solution but not who's move is now. And current process from my point of view is a Monte-Carlo issue picking. It's not broken -- speed is almost the same (cause it's the speed of commit process), but absolutely no feeling of control. Also after the review/commit separation, we'll be able to tell exactly, if we need more reviewers, patch writers/rewriters, core dev team members or just committers. >> Core devs have no time even to accept working & looking good >> patches -- and rarely have time to review patches not looking good or >> working wrong! >> So why should I bother to write patches fast? > > I would point out that the core team aren't the only people that can > give feedback. Trac is an open resource for exactly that reason. Yes, this is one more point. Regular developers, like me, also don't know what to review, and for most of patches, they just can't write a review: they have high risk of writing wrong suggestion. Patch author or triagers usually know if people can write a review, but people can't find such issues. So probably "reviewers" bugs category should also exist, but should be also treated differently. If we agree with such a system, I can walk through all issues (probably with scripts), and write who needs to respond on each issue. Patch developers usually know whether everyone wants feedback from them, but I'd love if we were able to reduce core developers load with introduction of such system and adding more reviewers. Think of the following: every personal django branch on github can be considered as adding a reviewer & committer. Why not ask them to help with tickets? But then they need to know how they can help. We outline issues to write patches for, but not for review. Since tickets with needs_better_patch=1 could be both reviewed or not reviewed, I haven't find any way to get any reviewing queue. On implementation side, I consider two checkboxes with "[ ] needs public review" and "[ ] needs core dev review", and a button with "(Set me as a curator on this issue)", or maybe a text input for curator email. That way, DDN stage might not be needed -- it's just "unreviewed" + "needs core dev review". Date of last ticket update can be also added to the trac reports -- to sort tickets based on that date. A robot can be written to fill these fields based on other fields, comments authors, and knowledge of who are in core dev team. I would also consider an external service for reviewing and triaging, but that way you won't see review states in trac. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
Re: #11834: colorized debug page. Assigned to buriy
On Sunday, August 15, 2010, burc...@gmail.com wrote: > Hi Russell, > >> However, it does need to have it's UX issues sorted out. The most >> recent substantive comment on the ticket [1] indicates that the patch >> isn't ready for checkin. It also suggests that there are broader >> improvements that may need consideration. To the best of my knowledge, >> nobody has tried to start a django-dev discussion to address those >> improvements. >> >> [1] http://code.djangoproject.com/ticket/11834#comment:5 > > Regarding ticket improvements, do you remember that guy who sent a > beautiful screenshot of his templates errors rework in the django dev > about half a year or a year ago? Can't find it, but I wanted > desperately to include it! Sorry - can't say I do. 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.
