Re: reconsider re-opening ticket 901

[Russell Keith-Magee]

On Sun, May 12, 2013 at 8:10 AM, Andrew Ingram wrote:

> On 12 May 2013, at 00:55, Russell Keith-Magee 
> wrote:
>
> I'm sure I understand this argument. Python objects are passed around by
> reference, not by value, so if you've passed in a Django object deep into
> another library, that library will be pointing at the same instance. If the
> instance is changed, everywhere holding a handle to that reference will be
> updated.
>
> To that end - I want to make sure that we're clear about what we're
> talking about here.
>
> What is on the table is essentially adding a refresh() call on an object
> instance that is an API analog of ".get(id=self.id)" (although the
> implementation will need to do a bit more than that).
>
> We are *not* talking about ticket #17, object instance caching. Calling
> refresh() *will not* update *every* instance of a given object. The
> following would be the effective API:
>
> >>> a = MyObj.objects.get(id=42)
> >>> a.message = 'hello'
> >>> a.save()
> >>> b = MyObj.objects.get(id=42)
> >>> c = MyObj.objects.get(id=42)
>
> >>> a.message = 'goodbye'
> >>> a.save()
> >>> print b.message
> 'hello'
> >>> b.refresh()
> >>> print b.message
> 'goodbye'
> >>> print c.message
> 'hello'
>
>
> I was under the impression that the suggested use case was more like this:
>
> >>> a = MyObj.objects.get(id=42)
> >>> a.message = 'hello'
> >>> b = {'obj': a}
> >>> print b['obj'].message
> 'hello'
> >>> c = MyObj.objects.get(id=42)
> >>> c.message = 'goodbye'
> >>> c.save()
> >>> a = MyObj.objects.get(id=42)  # existing 'workaround', gives us a new
> instance
> >>> print a.message
> 'goodbye'
> >>> print b['obj'].message  # b['obj'] still points to the original
> instance `a`
> 'hello'
>
> If a reload() method existed, `a` could have been reloaded with
> `a.reload()`, and then `b['obj']` would have been up-to-date as well. As it
> stands, every reference to `a` has to be explicitly re-fetched from the
> database.
>
> Am I missing something obvious?
>
> As far as I can make out, that's exactly the same use case -- you're just
making the example a little bit more explicit regarding the fact that 'a'
is an object referred to by reference, so if 'a' is updated, b['a'] will
also be updated.

The point I was trying to make is that we're *not* talking about every
instance of "object with PK 42" being transparently updated. It's an
explicit API call on a specific object instance.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[ApogeeGMail]

hi all:

Long time lurker. Would like to say that I have benefited greatly from the 
expertise on the group, and to extend my thanks to all the developers who have 
contributed with such undying enthusiasm to Django and the simple users and 
noobies on this list and the users group.

Having been in SW development for 30+ years, I think the approach of the BDFL 
is one of the best I have ever seen.

So, Thanks to all, from those you listen and lurk!!

Richard

On May 13, 2013, at 6:21 PM, Peter wrote:

> I have a thought on an action we could take out of this that might be 
> constructive. 
> 
> Would it be possible to customise trak at all to make the workflow clearer? 
> 
> I'm thinking if someone tries to open a ticket that was closed by a committer 
> then they should get an intermediate page pointing them to this group and 
> asking them to confirm before the ticket is reopened.
> 
> I don't know if Trak is customisable to that extent, or if this would even be 
> effective, but it would be nice to get something out of this.
> 
> Thanks,
> Pete
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 





-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Ryan Hiebert]

On May 13, 2013, at 3:21 PM, Peter  wrote:

> I have a thought on an action we could take out of this that might be 
> constructive. 
> 
> Would it be possible to customise trak at all to make the workflow clearer? 
> 
> I'm thinking if someone tries to open a ticket that was closed by a committer 
> then they should get an intermediate page pointing them to this group and 
> asking them to confirm before the ticket is reopened.
> 
> I don't know if Trak is customisable to that extent, or if this would even be 
> effective, but it would be nice to get something out of this.

If Trak is customizable enough, it might be good to have the ticket template 
always have a link to the Google Group. Label it "Google Group/Mailing List", 
and then a comment that says "let's move this discussion over to the mailing 
list" can be a simple click on a link, and you're at the mailing list. 
Hopefully, that could help to eliminate the overhead associated with getting 
the discussion to the right place to make progress.



smime.p7s
Description: S/MIME cryptographic signature

Re: Perception of attitude in tickets

[Jacob Kaplan-Moss]

On Mon, May 13, 2013 at 9:56 AM, Tom Evans  wrote:
> I don't think anyone is asking you to do this. This ticket in question
> wasn't lacking bandwidth from committers, it was visited many times by
> committers, who each time summarily dismissed the ticket - "We're not
> doing this because x years ago, God said thus".

Look, that's not what we said. If you insist on finding the most
negative characterization for our words and motivations, I don't
really see why we should engage you further.

Can you please try to assume some good faith on our part?

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Anders Steinlein]

On Mon, May 13, 2013 at 7:55 PM, Yo-Yo Ma  wrote:

> How about allowing comments only from the patch author and committers?
>>
>
> The problem I see with this is that original bug reporters, aside from the
> aforementioned groups, are usually the ones most engaged in these comments,
> and eliminating them from the process will only serve to further disjoint
> the technical dialog (e.g., "It's still not fixed" should probably go in
> the ticket, not here).
>

I actually meant the one opening the ticket as opposed to patch author,
thinking momentarily that they are one and the same. Ticket openers, patch
authors and committers should be allowed to comment in such a setup.

A.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Ticket 13978: Allow inline js/css in forms.Media

[Derek Payton]

I have a working patch with tests and docs for #13978, which would add the 
ability to have inline JS and CSS in forms.Media. I feel that this ticket 
is a much better solution than, e.g., scattering the required inline media 
throughout your templates. However the issue was raised that this goes 
against the W3C's Content Security Policy. Per Julian's recommendation, I 
am bringing this here for consideration.

Ticket: https://code.djangoproject.com/ticket/13978

CSP is an opt-in policy and must be supported by both the web application 
and the browser to be effective. Django itself does not support CSP out of 
the box (though django-csp[0] exists to facilitate this) and a bit over 
half of browsers currently support it[1]. I'm not sure how (or if) that 
affects this discussion.

Although the recommendation is to move all inline scripts and styles to 
external resources, the policy does include a mechanism to explicitly allow 
inline scripts and styles in the form of the "unsafe-inline" directive. 
This makes it pretty clear that you're losing a bit of CSP's protection by 
enabling this. Perhaps the docs could be updated with a warning for 
developers that want to take advantage of CSP?

I appreciate any thoughts, comments, and feedback.

Thanks,
--Derek

[0] https://github.com/mozilla/django-csp/
[1] http://caniuse.com/contentsecuritypolicy

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Joe Tennies]

As a fellow lurker (sorry I've been using Flask more recently), I think
this could simply be fixed via a form response. Here's a simple example:

This bug is being marked as "WONTFIX" because 

Please realize that every API/feature added to Django needs to be
maintained across several versions. The more public APIs that are exposed
to users, the more difficult it is to refactor and add other features. This
request currently lacks enough merit to exceed the cost it will add to the
maintenance of Django.

Possible solutions:
* Create a separate library to implement this feature. With enough use, the
merit may be more obvious.
* Start a discussion on https://groups.google.com/group/django-developers.
Please note that a stronger case will be needed to overturn this decision,
though the community may be able to help build that case. That community
may be best reached on https://groups.google.com/group/django-users or on
IRC at #django on irc.freenode.net.

Even the reasoning in the comment and the above via a link would help (to
allow the form to be updated if someone words it better). (can you make the
"WONTFIX" link to that description or do a mouse over comment box?


On Mon, May 13, 2013 at 5:21 PM, Peter  wrote:

> I have a thought on an action we could take out of this that might be
> constructive.
>
> Would it be possible to customise trak at all to make the workflow clearer?
>
> I'm thinking if someone tries to open a ticket that was closed by a
> committer then they should get an intermediate page pointing them to this
> group and asking them to confirm before the ticket is reopened.
>
> I don't know if Trak is customisable to that extent, or if this would even
> be effective, but it would be nice to get something out of this.
>
> Thanks,
> Pete
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
Joe Tennies
tenn...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Peter]

I have a thought on an action we could take out of this that might be 
constructive. 

Would it be possible to customise trak at all to make the workflow clearer? 

I'm thinking if someone tries to open a ticket that was closed by a committer 
then they should get an intermediate page pointing them to this group and 
asking them to confirm before the ticket is reopened.

I don't know if Trak is customisable to that extent, or if this would even be 
effective, but it would be nice to get something out of this.

Thanks,
Pete

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[AK]

On 05/13/2013 01:16 PM, Anders Steinlein wrote:

On Sun, May 12, 2013 at 2:06  AM, Russell Keith-Magee  
wrote:

>
>
> Looking for a positive outcome here -- my question to the 
community, and especially those that feel that we've been unresponsive 
here: how do we improve the situation?

>
>
> I've been lurking on this thread (and list in general for that 
matter), and thought I'd throw in my $.02 as someone interested in, but 
not (yet) involved in, development of Django itself.

>
> I very much understand the policy of having discussions on the 
mailing list (particularly in the view of duplicate/related tickets), 
but I also see (and sometimes myself feel) the frustration OP brought up.

>
> Why allow comments on tickets at all when discussions are meant to 
happen here? I understand the need to comment on the specifics of 
patches/doing reviews, but from a (new) user's point of view, those are 
just comments like any other. When some comments are welcome, but others 
are not, how are new user's supposed to know where to discuss what?

>
> How about allowing comments only from the patch author and 
committers? With a big fat informational text in place of the add 
comment section? How about adding a button/link directly to the Google 
Group with "open for discussion" or some such? Just throwing out some 
ideas here.

>
> Regards,
> Anders
> --


Perhaps a good rule would be: if you ask someone to raise the issue on
mailing list, a link to the google group page must always be given in
the same comment. It's reasonably easy and it's a lot more inviting to
give the link vs. "There's a mailing list out there somewhere, go and
find it, why don't you?" -ak

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[AK]

On 05/13/2013 12:11 PM, Luke Sneeringer wrote:



> On May 13, 2013, at 10:06 AM, AK  wrote:
>
>> WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can
>> be used instead, the effective meaning is the same, just the term itself
>> is more polite. It seems that nobody looking at it would think "I'll
>> just wait for a while and surely it'll get fixed.". Instead, anyone
>> needing it would think "If it is to be fixed, it's clear someone has
>> to make a case for it." -ak
>
> Note: "won't fix" is used on many bug systems, not just Django. So, 
in choosing to go for a euphemism, you're also (unintentionally) 
obfuscating, because you're subtly communicating that it's somehow 
different than the standard "won't fix".

>
> Best Regards,
> Luke Sneeringer
>


I should have mentioned that I know it's used on other bug systems, and
that I agree it's less clear. It's a tradeoff that you often have when
you try to be polite: the alternatives are usually more blunt and clear.
In this particular case, I don't think it's a problem because there are
only two choices here - either someone cares about the ticket being
fixed, or not.

If not, there's no problem. If yes, the main message will not be lost:
"this ticket isn't going to get fixed and you have to convince someone
if you want that to happen."

I agree 'onholdindefinite' is a bit awkward, I think it's a bit better
than wontfix but wontfix isn't terrible either.

 -ak

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Triaging: Close as needsinfo

[Aymeric Augustin]

Hi Shai,

On 11 mai 2013, at 22:58, Shai Berger  wrote:

> On one hand -- should I have closed it myself, and saved a core-dev the 
> trouble? The triaging guide[1] seems very inconclusive about this, advising 
> on 
> other reasons to close tickets but not on needsinfo (except "tickets which 
> are 
> really feature requests").

Yes, this is the best course of action. I'll clarify the contributing guide.

There are several reasons for this:
- it increases the signal-noise ratio in open tickets,
- often the reporter never responds because he moved on and no longer cares,
- we have to keep some balance between the efforts required from people who
  report bugs and those who attempt to reproduce them.

For this ticket, if the reporter were paying my consulting rate — and that's
not far fetched, he can afford Oracle licenses after all — he would certainly
provide a more thorough description of his problem. Giving away our time
doesn't make it less respectable or valuable.

> On the other hand -- especially, in the wake of the "Perception of attitude 
> in 
> tickets" brouhaha -- should we really be closing tickets on needsinfo? In 
> other communities, I have usually seen "needsinfo" as a ticket state, rather 
> than a reason for closing; such tickets are then closed later, if enough time 
> has passed and no further info is received. I realise that, when the person 
> closing the ticket specifically says "when you have more info, please 
> re-open" 
> (as Aymeric did in this case), then the process is essentially the same, only 
> a little more efficient; but I worry that this efficiency may carry a price 
> in, as 
> Simon put it, "perception of attitude in tickets". 


When a ticket is closed a "needsinfo", it also carries the message that the
ticket wasn't reported properly, and thus wasted a bit of everyone's time.
Closing the ticket reflects this, for better or worse.

> For what it's worth, I, personally, would feel much more at ease setting 
> tickets as "needsinfo" without closing them -- and if it's a ticket state, 
> there should be no problem taking such tickets out of the reports developers 
> use, so they're almost as far out of the way as closed tickets.

I don't think it's appropriate to ignore open tickets. If we're going to ignore
them, let's close them.

Plus, everything Carl said, and which I removed from my draft :)

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Aymeric Augustin]

On 13 mai 2013, at 21:15, Chris Wilson  wrote:

> I think it *IS* different to the standard "won't fix". The standard one 
> implies "won't fix EVER" to me, whereas I think the way Django uses this 
> status is "won't fix until someone persuades on the mailing list." Which 
> could be expressed better than that, I'm sure. I did suggest a couple of 
> other options: NEEDINFO and DISCUSSION. I could suggest some more: ITSAPONY? 
> JUSTIFY?

These are nuances, and nuances are better conveyed by comments in English than 
by states. If you look at tickets closed "wontfix", many also have a comment 
along the lines of "if you disagree please explain X and Y on the mailing-list".

Using a state instead of a full sentence would be less helpful. One-off 
contributors won't peruse the contributing guide to figure out what the state 
precisely means and what the next step is.

Having less states forces everyone to write complete comments, and I believe 
that's a good thing, even though it takes me a lot of time. It puts everyone on 
an equal footing, regardless of how familiar with the tracker they are.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Yo-Yo Ma]

There is a fundamental problem here, albeit one that is rooted in simple 
misunderstanding.

The burden of proof is on the originator of an idea (i.e., the ticket 
reporter). Arguments can be made against the idea in the ticket. Rebuttal 
is sent elsewhere. Regardless of the intention, this automatically creates 
contention (in some cases) because it appears as a double standard, as 
arbitrary discretion is used to draw a line in the sand (the point at which 
the discussion should be moved to the mailing list).

The solution could be either:

A) Allow for full discussion in a ticket (this may not be an option, based 
on the conversations I've read)

or

B) Disallow only technical (how to fix, code review, etc.) discussion in a 
ticket, and make it easy to get from a ticket to its discussion thread and 
back again.

Option A allows for easier collaboration on business aspects by 
incorporating technical considerations into the conversation at the expense 
of extra noise.
Option B allows for easier digestion of either tech or business at the 
expense of a lack of cohesion among both parties.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Chris Wilson]

On Mon, 13 May 2013, Kirby, Chaim [BSD] - PED wrote:

WONTFIX has a long history in software development. It also does 
(correctly) state intentionality that 'onholdindefinite' lacks. The 
intention of WONTFIX is "yes, this is possibly valid, but in the state 
this ticket is written it is being closed". Using anything else that 
doesn't close the ticket just lets it hang out as cruft.   


I'm OK with it being a closed state, if that helps. I'd just prefer a 
slightly friendlier name for it.


Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Chris Wilson]

Hi Luke,

On Mon, 13 May 2013, Luke Sneeringer wrote:

On May 13, 2013, at 10:06 AM, AK  wrote:

WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can 
be used instead, the effective meaning is the same, just the term 
itself is more polite. It seems that nobody looking at it would think 
"I'll just wait for a while and surely it'll get fixed.". Instead, 
anyone needing it would think "If it is to be fixed, it's clear someone 
has to make a case for it." -ak


Note: "won't fix" is used on many bug systems, not just Django. So, in 
choosing to go for a euphemism, you're also (unintentionally) 
obfuscating, because you're subtly communicating that it's somehow 
different than the standard "won't fix".


I think it *IS* different to the standard "won't fix". The standard one 
implies "won't fix EVER" to me, whereas I think the way Django uses this 
status is "won't fix until someone persuades on the mailing list." Which 
could be expressed better than that, I'm sure. I did suggest a couple of 
other options: NEEDINFO and DISCUSSION. I could suggest some more: 
ITSAPONY? JUSTIFY?


I think we're lucky to have a community where it's possible to persuade 
the BDFLs to change their minds, and unlucky to have an unfriendly-looking 
bug tracker which dissuades people from trying.


Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Shai Berger]

Hi Tom,

On Monday 13 May 2013, Tom Evans wrote:
> 
> You're not the only person who has time constraints, each of has a
> choice of what we work on in our spare time. When I read these sorts
> of tickets, perfectly valid feature requests knocked down for
> precisely no reason, why should I waste my time trying to jump through
> these arbitrary hoops? The short answer is I don't, I work on my own
> projects.
> 
You are missing two crucial points:

> perfectly valid feature requests knocked down for precisely no reason

1) The feature requests you are talking about have all been considered and 
rejected by committers. There is an assumption that committers do want to 
improve Django and do not reject suggestions at a whim; that there is a reason 
for the rejection. You may not like the reason, but that's a different story 
and point.

> why should I waste my time trying to jump through these arbitrary hoops?

2) The "hoops" are not arbitrary. I see two points in the requirement to go to 
the mailing list:

- The point mentioned many times in this discussion: The mailing list is much 
more visible than any single ticket.

- Saving committers' time. While it's true that
> You're not the only person who has time constraints
committer time is the most scarce resource of the Django community. So if a 
committer has already spent some time on a ticket, I'd rather have some other 
people look at it before requiring committers' attention again.

My (non-committer's) 2 cents,

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Yo-Yo Ma]

>
> How about allowing comments only from the patch author and committers?
>

The problem I see with this is that original bug reporters, aside from the 
aforementioned groups, are usually the ones most engaged in these comments, 
and eliminating them from the process will only serve to further disjoint 
the technical dialog (e.g., "It's still not fixed" should probably go in 
the ticket, not here).
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Anders Steinlein]

On Sun, May 12, 2013 at 2:06 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> Looking for a positive outcome here -- my question to the community, and
> especially those that feel that we've been unresponsive here: how do we
> improve the situation?
>

I've been lurking on this thread (and list in general for that matter), and
thought I'd throw in my $.02 as someone interested in, but not (yet)
involved in, development of Django itself.

I very much understand the policy of having discussions on the mailing list
(particularly in the view of duplicate/related tickets), but I also see
(and sometimes myself feel) the frustration OP brought up.

Why allow comments on tickets at all when discussions are meant to happen
here? I understand the need to comment on the specifics of patches/doing
reviews, but from a (new) user's point of view, those are just comments
like any other. When some comments are welcome, but others are not, how are
new user's supposed to know where to discuss what?

How about allowing comments only from the patch author and committers? With
a big fat informational text in place of the add comment section? How about
adding a button/link directly to the Google Group with "open for
discussion" or some such? Just throwing out some ideas here.

Regards,
Anders

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Tom Evans]

On Mon, May 13, 2013 at 4:10 PM, Jacob Kaplan-Moss  wrote:
> Hi Tom --
>
> It really sucks that when I say "if you have feedback please send it
> over here", you hear "I'm not listening".
>
> I'm sorry, but I don't have the mental bandwidth to follow 20,000
> individual tickets. It's impossible. I just fucking can't do it.
> Believe me, I've tried, and failed, many times. I'm sorry I'm such a
> slacker.

I don't think anyone is asking you to do this. This ticket in question
wasn't lacking bandwidth from committers, it was visited many times by
committers, who each time summarily dismissed the ticket - "We're not
doing this because x years ago, God said thus". There was enough
mental bandwidth for it to be covered 4 times over.

I'm aware that I'm simplifying a complex scenario by reducing it to a
single case, but this is the kind of response I've seen all over
tickets, emails and so on.

You're not the only person who has time constraints, each of has a
choice of what we work on in our spare time. When I read these sorts
of tickets, perfectly valid feature requests knocked down for
precisely no reason, why should I waste my time trying to jump through
these arbitrary hoops? The short answer is I don't, I work on my own
projects.

What I read in the OP was someone who felt in a similar situation.

>
> I *do* have the bandwidth to follow a single mailing list. If you want
> my attention, that's how you get it.
>
> If you really want to help, if you really want to get a positive
> outcome from this, then how about you give me a hand and follow (part
> of) Trac for me? Watch some tickets, and if/when they get stalled
> bring them here.

Ho hum, so a lack of engagement with parts of the community is my fault is it?

I have to stay current with Django to be competent at my job, which
means following these mailing lists. I also benefit from Django, so I
feel compelled to help out as I can, which I do by contributing to
users@.

When it comes to open source work, you can't compel people to work on
what you want them to work on, people will work on what they want to
work on. If you make it so that it is hard for them to work on it,
they won't work on your project. If you look objectively at both mine
and the OPs posts, ignore the bits that make you angry, maybe you will
see that you're losing potential contributors. Maybe you won't, I'll
go back to lurking.

This is your project, so how you structure it and accept feedback is
entirely under your control. You could set something up to mail
developers@ iff a ticket is re-opened after being closed if you want
the discussion on here and not on tickets. At the moment, you invite
people to make comments on tickets and then ignore them.

The problem that I thought this thread was discussing was "Why do lots
of people feel there is an engagement issue". If only I had known that
it was about finding mugs to do triage..

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Alex Ogier]

On Sun, May 12, 2013 at 3:05 PM, Chris Wilson  wrote:

> Hi all,
>
>
> On Sun, 12 May 2013, Shai Berger wrote:
>
>  those should probably be updated (on remote objects!) too, or else some
 serious inconsistencies may be created (when the _id field changes, that
 is).

>>>
>> aa= A.objects.get(...)
>> bb= aa.b
>> (some other operation, changing aa.b_id in the database)
>> aa.refresh()
>>
>> Now -- unless we do something about it -- bb.a is still aa, but aa.b is
>> not bb
>> and not even equal to it; thus, "bb.a.b == bb" is false, which currently
>> cannot happen without serious meddling if I'm not mistaken.
>>
>
> Hibernate (as an implementation of the Java Persistence API, JPA) tries to
> do things like this by implementing a global cache of objects loaded from
> the database, so that there's only one copy of A and B in memory, which all
> references point to.
>
> This makes it possible for A, when its link to B changes to point to a
> different object B', to find all the instances of B in memory (because
> there's only one, and it's in the object cache) and update them to no
> longer point back to A.
>
> However it does this at enormous cost in flexibility, sanity and error
> recovery. I strongly recommend against going down this route:
> http://blog.old.aptivate.org/**2010/11/26/hibernate-ejb-and-**
> the-unique-constraint/
>
> It's always possible to have an out-of-date model object in memory with
> Django, with or without refresh() (which just allows us to update it
> manually). I suggest we let that sleeping dog lie.


It does make sense to do this though, in the particular case of one-to-one
relationships (for the same reasons it makes sense to cache back-references
in one-to-one relationships). The reason is that this maintains a
python-only invariant that is independent of whether the relationship is
persistent in the database. There's no attempt to update all model
instances of the referred-to model, only the single one that is currently
referred to by the Python instance. This is consistent with the behavior of
setting a OneToOneField to None. For example consider the following:

bb = B()
bb.save()
aa = A(b=bb)
aa.save()
assert aa.b is bb
assert bb.a is aa   # back-reference is cached

aa.b = None   # back-reference is cleared
assert aa.b is None
assert bb.a is None

This should be consistent with the behavior when .refresh() is called -- if
that involves clearing aa.b, then bb.a should also be cleared, it's that
simple. Ideally this is done by just setting all fields via setattr(),
which will trigger this code (and any arbitrary code for user-defined
fields Django doesn't know about). In short the following should be
equivalent to the previous example:

bb = B()
bb.save()
aa = A(b=bb)
aa.save()
assert aa.b is bb
assert bb.a is aa   # back-reference is cached

aaa = A.objects.get(id=aa.id)
aaa.b = None
aaa.save()

aa.refresh()   # back-reference is cleared
assert aa.b is None
assert bb.a is None

Hopefully that clears things up.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Michael Manfre]

I think it's better to follow the convention used by almost every other bug
tracker and stick with WONTFIX. Changing the name will be confusing. I
think the best route forward is to not take bug status wording as a
personal offense and be happy that those that set the status almost always
give an explanation as to why the case is being closed.

Regards,
Michael Manfre


On Mon, May 13, 2013 at 12:06 PM, AK  wrote:

>  On 05/13/2013 11:23 AM, Jacob Kaplan-Moss wrote:
> > On Mon, May 13, 2013 at 2:12 AM, Chris Wilson 
> > wrote:
> >> The status WONTFIX sounds awfully rude to me.
> >
> > I've thought so, too, but every time I've tried to come up with an
> > alternate name I've failed. Any suggestions?
>
>
> WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can
> be used instead, the effective meaning is the same, just the term itself
> is more polite. It seems that nobody looking at it would think "I'll
> just wait for a while and surely it'll get fixed.". Instead, anyone
> needing it would think "If it is to be fixed, it's clear someone has
> to make a case for it." -ak
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Kirby, Chaim [BSD] - PED]

On 05/13/2013 11:06 AM, AK wrote:
On 05/13/2013 11:23 AM, Jacob Kaplan-Moss wrote:
> On Mon, May 13, 2013 at 2:12 AM, Chris Wilson 
>  wrote:
>> The status WONTFIX sounds awfully rude to me.
>
> I've thought so, too, but every time I've tried to come up with an
> alternate name I've failed. Any suggestions?


WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can
be used instead, the effective meaning is the same, just the term itself
is more polite. It seems that nobody looking at it would think "I'll
just wait for a while and surely it'll get fixed.". Instead, anyone
needing it would think "If it is to be fixed, it's clear someone has
to make a case for it." -ak
WONTFIX has a long history in software development. It also does (correctly) 
state intentionality that 'onholdindefinite' lacks. The intention of WONTFIX is 
"yes, this is possibly valid, but in the state this ticket is written it is 
being closed". Using anything else that doesn't close the ticket just lets it 
hang out as cruft.

--
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Luke Sneeringer]

On May 13, 2013, at 10:06 AM, AK  wrote:

> WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can
> be used instead, the effective meaning is the same, just the term itself
> is more polite. It seems that nobody looking at it would think "I'll
> just wait for a while and surely it'll get fixed.". Instead, anyone
> needing it would think "If it is to be fixed, it's clear someone has
> to make a case for it." -ak

Note: "won't fix" is used on many bug systems, not just Django. So, in choosing 
to go for a euphemism, you're also (unintentionally) obfuscating, because 
you're subtly communicating that it's somehow different than the standard 
"won't fix".

Best Regards,
Luke Sneeringer

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Jacob Kaplan-Moss]

Hi Tom --

It really sucks that when I say "if you have feedback please send it
over here", you hear "I'm not listening".

I'm sorry, but I don't have the mental bandwidth to follow 20,000
individual tickets. It's impossible. I just fucking can't do it.
Believe me, I've tried, and failed, many times. I'm sorry I'm such a
slacker.

I *do* have the bandwidth to follow a single mailing list. If you want
my attention, that's how you get it.

If you really want to help, if you really want to get a positive
outcome from this, then how about you give me a hand and follow (part
of) Trac for me? Watch some tickets, and if/when they get stalled
bring them here.

Jacob



On Mon, May 13, 2013 at 2:13 AM, Tom Evans  wrote:
> On Mon, May 13, 2013 at 3:51 AM, Russell Keith-Magee
>  wrote:
>> My apologies if I wasn't clear - that wasn't what I was saying at all. What
>> I meant is that we can't institute a process like "Every core developer must
>> spend 4 hours per week triaging tickets or they will lose their core
>> developer status". This would be a completely reasonable course of action if
>> you were a paid employee -- your employer is just telling you what you have
>> to do to get paid -- but that dynamic doesn't exist in a volunteer project.
>> In a volunteer project the only reason the "hard" stuff gets done is because
>> people volunteer to do it.
>>
>> However, in this case, Jacob *did* give a detailed explanation:
>>
>> "This seems like a needless function; it's already possible to just
>> re-look-up the object from the database."
>>
>> It was rejected because the need wasn't clear. Simon then reopened the
>> ticket, and gave a detailed use case, to which Jacob responded:
>>
>> "I'm really not convinced by Simon's use case -- adding "reload()" only
>> saves you a single line of code. Let's do our best to keep Django as svelte
>> as possible."
>>
>> What more detail should Jacob have provided? The feature isn't that complex.
>> It's not like he's got an opportunity to present a PhD thesis in relational
>> algebra. It's a simple feature, which has been rejected because in Jacob's
>> opinion, it can be achieved in other ways.
>>
>> Jacob didn't explicitly call for a discussion on the mailing list. Perhaps
>> he should have. However, when the ticket was reopened for the second time,
>> James Bennett (ubernostrum) pointed at project policy to have these
>> discussions on the mailing list.
>>
>> What should James have done instead?
>>
>
> Perhaps the issue is that there is a feeling that no-one is listening
> to the community? This particular issue was shot down because a core
> dev didn't like the style of the change. They felt that adding a
> function to be explicit about reloading an object is wrong since it
> bloats django.
>
> This was decided 5 years ago, communicated in a single line. Any
> attempt by the community to say "wait a minute, I'd really like this"
> gets shot down and told to bring it here, or worse. 3 days ago, the
> response was "If you want it, you have to make it happen."
>
> Perhaps this wasn't clear, that was a member of your community trying
> to make it happen. There have been several attempts over the past 5
> years by people trying to make it happen. Each time someone has tried
> to make it happen, after the initial attempt, the ticket has been
> re-closed "BFDL already said no, just go away".
>
> In this case, happy days, a few hours of discussion on the ML, and
> this ticket is now accepted. You need to understand that not all of
> your users are comfortable or capable of advocating on mailing lists,
> but are happy to contribute to tickets. With this ticket, 5 years of
> asking for this feature on the ticket was pointless, and this is what
> the OP is railing against. You gave people a way to contribute, but
> then ignore them. Perhaps "ML or GTFO" if not the right approach for
> attracting contributors.
>
> Cheers
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: first() and last(), earliest() and latest()

[Michal Petrucha]

> > I initially modeled "first()" and "last()"'s behaviors to mimic 
> > "latest()", but in this new pull request, you can pass multiple field names 
> > into "first()" and "last()" so it behaves like "order_by()". It's more 
> > flexible and requires less typing, but I wonder if we should just get rid 
> > of the optional field arguments and rely on "order_by" for ordering. "There 
> > should be one-- and preferably only one --obvious way to do it".
> 
> Considering "There should be one-- and preferably only one --obvious way to 
> do it", I definitely prefer to rely on order_by to do the ordering, not on 
> first. 
> 
> .order_by('name').first()
> 
> is clear and readable in my opinion.

My thoughts exactly, we already have one method that does ordering, I
don't think it is necessary to make these methods incorporate that
functionality. If we did, we might argue that other QuerySet
operations could be supported as well and that would just result in a
bloated API. Especially if there's no performance gain (the QuerySet
would be cloned anyway), and it only saves a few lines of code.

Also, skimming through this thread, I think there was a consensus on
first() and last() not taking any ordering arguments, i.e. the first
proposed syntax:

.filter(last_name__startswith='b').order_by('last_name').first()

Michal


signature.asc
Description: Digital signature

Re: Perception of attitude in tickets

[Łukasz Rekucki]

On 13 May 2013 11:12, Chris Wilson  wrote:

> Hi all,
>
>
> On Mon, 13 May 2013, Russell Keith-Magee wrote:
>
>  This isn't political equivocating. Its a genuine call to the community to
>> tell us how we can make things better.
>>
>
> If I may make a suggestion to be considered by the community:
>
> The status WONTFIX sounds awfully rude to me. It's like saying "That's a
> pony and you can't have one, ever." It implies a terminal finality which
> actually isn't meant in some cases, because it is possible (as we've seen)
> and even sometimes recommended by a core developer, for a sufficiently
> determined person to push for change on the mailing list and make it happen.
>

You can blame this on my lack of social skills, but I really don't see how
it's rude. It's informative: in current state the issue won't be fixed.
Yes, it is possible to change the status to Accepted, but only if new facts
arise (i.e. change of ecosystem, change in design). Note that the current
proposal for refresh() differs significantly from the original one and
that's the reason for accepting, not a core dev's change of heart. You
can't have *that* pony, but it doesn't mean you can have *any* ponies.


>
> Perhaps there's a case for a status like "DISCUSSION" or "NEEDINFO" when a
> feature might be accepted if sufficient evidence for it comes to light, but
> that evidence isn't there yet.
>

I fear it will end the same way as "Design Decision Needed" aka. Limbo.
It's a really horrifying state where the issue is nor dead nor alive and
lingers for all eternity causing even greater frustration for both the
reporter and developers.


> I think there is value in people "voting" for a feature on the ticket if
> they don't feel up to arguing the case on the mailing list (which is a
> trial by fire, and not for the faint hearted). Whoever is brave enough to
> take up the issue on the mailing list can point to the number of votes on
> the ticket as evidence for a desire for the feature, and hence its
> usefulness. And voting on the ticket instead of here saves a lot of "me
> too" noise on the mailing list.
>

In my experience, people will vote for issue without giving much thought
about it because clicking on a webpage doesn't cost anything, while
presenting reasonable arguments on a mailing list requires at least a
little research.  Also, you would need negative votes and I suspect that
would probably cause even more tension then "WONTFIX" status.

Although there is one major flaw in the voting system/tracker I sometimes
see: -1 votes (setting WONTFIX is effectively a veto just like -1) without
giving conditions for improvement to at least -0. Having a clear path of
action (even a one that involves a lot of work) to convince the person
vetoing your proposal is always better then just "No, I don't think it's
useful".


-- 
Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Donald Stufft]

On May 13, 2013, at 5:12 AM, Chris Wilson  wrote:

> Hi all,
> 
> On Mon, 13 May 2013, Russell Keith-Magee wrote:
> 
>> This isn't political equivocating. Its a genuine call to the community to 
>> tell us how we can make things better.
> 
> If I may make a suggestion to be considered by the community:
> 
> The status WONTFIX sounds awfully rude to me. It's like saying "That's a pony 
> and you can't have one, ever." It implies a terminal finality which actually 
> isn't meant in some cases, because it is possible (as we've seen) and even 
> sometimes recommended by a core developer, for a sufficiently determined 
> person to push for change on the mailing list and make it happen.
> 
> Perhaps there's a case for a status like "DISCUSSION" or "NEEDINFO" when a 
> feature might be accepted if sufficient evidence for it comes to light, but 
> that evidence isn't there yet.
> 
> I'd like to feel that reload() and first() are cases where a core developer 
> might choose to close a ticket with this new status instead of WONTFIX. I 
> would also hope that the core developers might be gentler with newbies like 
> me instead of scaring us off with a gruff one-word reply of WONTFIX.
> 
> I think there is value in people "voting" for a feature on the ticket if they 
> don't feel up to arguing the case on the mailing list (which is a trial by 
> fire, and not for the faint hearted). Whoever is brave enough to take up the 
> issue on the mailing list can point to the number of votes on the ticket as 
> evidence for a desire for the feature, and hence its usefulness. And voting 
> on the ticket instead of here saves a lot of "me too" noise on the mailing 
> list.
> 
> Cheers, Chris.
> -- 
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
> 
> Aptivate is a not-for-profit company registered in England and Wales
> with company number 04980791.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 

I think the problem with voting on an issue is that it will make people feel 
justified in asking/demanding a feature that doesn't have a chance of going on. 
A bad idea with a 100 yes votes isn't going to get in any more than a bad idea 
with 1 yes vote.

That's not to say it's not an ok idea. I don't know if it is or not. But it is 
an issue and folks will feel like # of votes justifies bad ideas getting 
implemented.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: test discovery

[Daniel Lindsley]

Russ & Carl,


I'm interested in this one, so I sketched up a potential avenue tonight 
(https://github.com/toastdriven/django/compare/check_setup). I actually 
implemented Russ' setup first, but ran into a couple issues, so I pared it 
down into an "opt-in" scheme. If there's a feeling like this is a 
worthwhile start, I'd be happy to flesh it out further, adding tests docs, 
refinements, etc. If not, no big deal.


Daniel



On Friday, May 10, 2013 8:32:38 PM UTC-7, Carl Meyer wrote:
>
> On Thursday, May 9, 2013 8:15:02 PM UTC-4, Russell Keith-Magee wrote:
>
>> On Thu, May 9, 2013 at 11:30 PM, Carl Meyer  wrote:
>>
>>> Hi Russ,
>>>
>>> On 05/09/2013 04:51 AM, Russell Keith-Magee wrote:
>>> > Great work Carl and Preston! (And everyone else who had a hand in the
>>> > patch - I know this has been kicking around for a while now)
>>>
>>> Thanks for the reminder; I should have mentioned that Mahdi Yusuf did
>>> the initial draft patch, based on Jannis' django-discover-runner, which
>>> was based on code I showed on a slide in my "Django and Testing" talk at
>>> PyCon 2012; it all comes full circle :-)
>>>
>>> > I agree with Jacob's tests aren't production sensitive, so making a 
>>> fast
>>> > transition to the new test discovery has less impact.
>>> >
>>> > However, we know from experience that it doesn't matter how much we 
>>> flag
>>> > this change in the release notes, they won't be read, and *someone* is
>>> > going to get stung. In an ideal world, it would be good to be able to
>>> > warn people who upgrade that their test suite may not be run as 
>>> expected.
>>> >
>>> > We've had a proposal kicking around for a while to add a management
>>> > command that does an "upgrade check". I'm wondering if this might be an
>>> > opportune time to dig into this some more.
>>> >
>>> > To be clear, this isn't something I consider to be a merge blocker. I'd
>>> > be happy to see 1.6 released with a fast transition to the new test
>>> > runner. It would just be nice icing on the cake if we can get an 
>>> upgrade
>>> > validator included in the same release.
>>>
>>> It wouldn't be too hard to write something that tried test discovery
>>> using the old runner and using the new runner and did a simple
>>> comparison of test counts to warn you if they differ.
>>>
>>> I'm not personally likely to work on this "upgrade checks" framework,
>>> but if it does happen I'd be happy to contribute this check to it.
>>
>>  
>> I thought about that approach, but my immediate reaction was that it will 
>> end up producing more false positives than helpful feedback. Even the 
>> simple case -- myapp.TestCase -> myapp.tests.TestCase -- is going to 
>> require some name munging to work out if the old test and the new test are 
>> actually the same one. Since this is for a short-lived transitional tool, 
>> the effort involved in getting it right exceeds the value gained by having 
>> it, IMHO.
>>
>
> I wasn't anticipating trying to actually match up individual tests by 
> name/path, just trying both runners and seeing whether the test counts 
> match. On second thought, though, I realize that contrib / third-party apps 
> will mean this check would alert "missing tests!" for pretty much everyone, 
> so it would need to be smarter to be useful, and you're right that's likely 
> not worth it.
>  
>
>> I'd prefer something much simpler:
>>
>>  * On syncdb/validate, check for a marker somewhere in user space. 
>>
>>  * If the marker isn't present, do a check for likely problems. In this 
>> case, look for the value of TEST_RUNNER; if it's set to the new default 
>> value, display a warning about the change in test discovery format. Add 
>> similar checks for other setting changes, or warnings about features that 
>> have been fully deprecated (e.g., the final transition of the {% url %} 
>> behavior)
>>
>>  * Provide a management command to set marker. 
>>
>>  * On the next syncdb/validate, the marker is present, so the install is 
>> verified as being "updated", and no warnings are displayed.
>>
>> This leaves the question of where to put the marker. Some initial ideas:
>>
>>  - a file on disk (e.g., an .updated file next to the settings file)
>>  - a new setting (VERIFIED_VERSION = "1.5")
>>  - a key-value table in a database used only for Django administrivia
>>
>> Essentially, this would give us a place to put the "NO REALLY, READ THIS" 
>> warnings that we need in release notes, and make those messages slightly 
>> targeted.
>>
>
> In theory this makes sense to me, but I think the question of where to put 
> the "I already ran the upgrade check" marker is thorny. Database is ugly, 
> since there's no requirement for a Django project to even use the ORM at 
> all; and requiring projects using the ORM to have a magical extra 
> not-related-to-a-voluntarily-installed-app table in their database sticks 
> in my craw. Similar with adding a file to the filesystem; we'd essentially 
> be requiring everyone to have 

Re: reconsider re-opening ticket 901

[Chris Wilson]

Hi all,

On Sun, 12 May 2013, Shai Berger wrote:

those should probably be updated (on remote objects!) too, or else 
some serious inconsistencies may be created (when the _id field 
changes, that is).


aa= A.objects.get(...)
bb= aa.b
(some other operation, changing aa.b_id in the database)
aa.refresh()

Now -- unless we do something about it -- bb.a is still aa, but aa.b is not bb
and not even equal to it; thus, "bb.a.b == bb" is false, which currently
cannot happen without serious meddling if I'm not mistaken.


Hibernate (as an implementation of the Java Persistence API, JPA) tries to 
do things like this by implementing a global cache of objects loaded from 
the database, so that there's only one copy of A and B in memory, which 
all references point to.


This makes it possible for A, when its link to B changes to point to a 
different object B', to find all the instances of B in memory (because 
there's only one, and it's in the object cache) and update them to no 
longer point back to A.


However it does this at enormous cost in flexibility, sanity and error 
recovery. I strongly recommend against going down this route:

http://blog.old.aptivate.org/2010/11/26/hibernate-ejb-and-the-unique-constraint/

It's always possible to have an out-of-date model object in memory with 
Django, with or without refresh() (which just allows us to update it 
manually). I suggest we let that sleeping dog lie.


Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Shai Berger]

Hi,

On Monday 13 May 2013, Tom Evans wrote:
> 
> Perhaps this wasn't clear, that was a member of your community trying
> to make it happen. There have been several attempts over the past 5
> years by people trying to make it happen. Each time someone has tried
> to make it happen, after the initial attempt, the ticket has been
> re-closed "BFDL already said no, just go away".
> 
> In this case, happy days, a few hours of discussion on the ML, and
> this ticket is now accepted. You need to understand that not all of
> your users are comfortable or capable of advocating on mailing lists,
> but are happy to contribute to tickets. With this ticket, 5 years of
> asking for this feature on the ticket was pointless, and this is what
> the OP is railing against. You gave people a way to contribute, but
> then ignore them. Perhaps "ML or GTFO" if not the right approach for
> attracting contributors.
> 

I'm trying hard to get something positive out of this. There are two points I 
see, which may be valid:

- For some users, "a mailing list" sounds like some arcane thing that requires 
specialized, "old-people" software to access. For those users, it may make a 
difference if we just point out that the mailing list is a Google Group and 
they can post to it through the web; just add a link when we send them to the 
mailing list. In ticket 901, links to the mailing list were only posted by 
Wim, after he had raised the discussion.

- The mailing list (through mail or through the web) requires you to be 
registered before you can post, while Trac allows anonymous posting. I am all 
for the argument that if one can't be bothered to register, they can't be seen 
as "trying to make it happen" -- it's just that the mailing list has one more 
little bump on the way to making a statement.

Other than that, I really can't grasp how "go to the mailing list" is 
interpreted as "go away".

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Tom Evans]

On Mon, May 13, 2013 at 3:51 AM, Russell Keith-Magee
 wrote:
> My apologies if I wasn't clear - that wasn't what I was saying at all. What
> I meant is that we can't institute a process like "Every core developer must
> spend 4 hours per week triaging tickets or they will lose their core
> developer status". This would be a completely reasonable course of action if
> you were a paid employee -- your employer is just telling you what you have
> to do to get paid -- but that dynamic doesn't exist in a volunteer project.
> In a volunteer project the only reason the "hard" stuff gets done is because
> people volunteer to do it.
>
> However, in this case, Jacob *did* give a detailed explanation:
>
> "This seems like a needless function; it's already possible to just
> re-look-up the object from the database."
>
> It was rejected because the need wasn't clear. Simon then reopened the
> ticket, and gave a detailed use case, to which Jacob responded:
>
> "I'm really not convinced by Simon's use case -- adding "reload()" only
> saves you a single line of code. Let's do our best to keep Django as svelte
> as possible."
>
> What more detail should Jacob have provided? The feature isn't that complex.
> It's not like he's got an opportunity to present a PhD thesis in relational
> algebra. It's a simple feature, which has been rejected because in Jacob's
> opinion, it can be achieved in other ways.
>
> Jacob didn't explicitly call for a discussion on the mailing list. Perhaps
> he should have. However, when the ticket was reopened for the second time,
> James Bennett (ubernostrum) pointed at project policy to have these
> discussions on the mailing list.
>
> What should James have done instead?
>

Perhaps the issue is that there is a feeling that no-one is listening
to the community? This particular issue was shot down because a core
dev didn't like the style of the change. They felt that adding a
function to be explicit about reloading an object is wrong since it
bloats django.

This was decided 5 years ago, communicated in a single line. Any
attempt by the community to say "wait a minute, I'd really like this"
gets shot down and told to bring it here, or worse. 3 days ago, the
response was "If you want it, you have to make it happen."

Perhaps this wasn't clear, that was a member of your community trying
to make it happen. There have been several attempts over the past 5
years by people trying to make it happen. Each time someone has tried
to make it happen, after the initial attempt, the ticket has been
re-closed "BFDL already said no, just go away".

In this case, happy days, a few hours of discussion on the ML, and
this ticket is now accepted. You need to understand that not all of
your users are comfortable or capable of advocating on mailing lists,
but are happy to contribute to tickets. With this ticket, 5 years of
asking for this feature on the ticket was pointless, and this is what
the OP is railing against. You gave people a way to contribute, but
then ignore them. Perhaps "ML or GTFO" if not the right approach for
attracting contributors.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Aymeric Augustin]

On 13 mai 2013, at 04:51, Russell Keith-Magee  wrote:

> The core team has implemented a process that we think works. It has changed 
> over time, and is something that we feel is practical to implement, and 
> achieves the goals we're aiming to achieve.


Not only do we think it works, but we have positive evidence that it does.

Wim Feijen did what we repeatedly suggested on the ticket that sparked this 
discussion: he started a discussion on this mailing-list. His post piqued the 
interest of Anssi, and as a result, the ticket is now accepted with a plausible 
implementation plan.

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.