Unsolicited mentorship requests

[Elena Williams]

Hiya team,

I'm confident that this is the wrong place to ask -- which list is the
correct to have this conversation?

Just want to bring this up in case it's a "Thing"[tm] now, that I have
missed: this last week I've had 3 different non-Australia
non-female-presenting individuals who I don't know solicit me privately on
social media for personal Django "mentorship". Frankly it's made me feel
pretty uncomfortable, but I've never been approached like this so rather
than just ruminating I thought I should just ask around if any one is
familiar with this happening? It's just several in a short window of time
seemed like a weird pattern.

Any advice appreciated,
---
Elena Williams
Github: elena <http://github.com/elena/>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMRRKVfZUreoB7F7Cc0t%2BGbs0GuqK%2Bpo4-wckQzS4GX-c96QuQ%40mail.gmail.com.

Re: Property-based "fuzzy" testing (Hypothesis) in Django

[Elena Williams]

Heya Adam,

Amazing! Thank you! You're correct that it's slower.

I'd completely forgotten about FactoryBoy! though used it a fair bit a few
years ago. Interesting to note that the original ruby project renamed
itself to FactoryBot
<https://github.com/thoughtbot/factory_bot/blob/master/NAME.md> ("offensive
or problematic" indeed).

The conversation continued about Factory* libraries, and Zac agrees that
these are useful, but has reservations that examples generated by them are
fewer, and more limited in range, eg omitting empty string, control
characters -- which is important for "real" bug finding, this is usualy bug
gold. He also reckons that they have weaker support for reproducing
failures.

Long and the short is possibly that FactoryBoy could be improved and maybe
there might be cases for Django projects to use Hypothesis too :) Whatever
happens I'm going to keep plugging away at hypothesis examples, and maybe
making the official docs, er, more penetrable. Personally I'm doing
something nuts, for which FactoryBoy is not suitable, so this makes sense
in my case.

It's great to hear about the OSS-Fuzz project. I've passed the details
along. It's always nice to cross-polinate and delighted Zac'll be packing
for PyCon with this background under his belt. It seems likely more
conversation will be happening there.

Thank you so much again,
---
Elena Williams
Github: elena <http://github.com/elena/>


On Fri, 21 Feb 2020 at 20:22, Adam Johnson  wrote:

> Hi Elena,
>
> I like fuzz testing and how Hypothesis does it. I have used it on a couple
> of projects and it always found bugs. In fact it was my first Pycon that I
> sat with David and sprinted on adding it to a project :)
>
> That said I've always found it quite a leap from straightforward tests,
> being slower and non-deterministic. There is a hard balance to make writing
> fuzz tests versus writing individual test cases to ensure edge cases keep
> being covered. And also we generally want tests to be less complex than the
> code they are testing - short functions with several parameters can easily
> need many lines of hypothesis code to set up accurate testing.
>
> Personally I tend to settle on using a little bit of fuzzing with random
> data from factory boy, but adding control to the random seed used in
> testing using pytest-randomly. I gave this approach a bit of a write up
> when I started using it in 2014:
> https://adamj.eu/tech/2014/09/03/factory-boy-fun/ .
>
> As for Django's test sutie: I don't believe there is any fuzz testing
> there. But it is being tested separately instead with Google's OSS-Fuzz
> project: https://github.com/google/oss-fuzz/tree/master/projects/django .
> This was set up by Guido Vranken who announced it in this mailing list
> thread:
> https://groups.google.com/forum/#!topic/django-developers/-WweB07YiVQ .
> Apparently it has caught a few bugs since implementation, and there's scope
> to expand it quite a lot:
> https://groups.google.com/d/msg/django-developers/PMtvmMlsjyw/_rOj_LzvCQAJ
> . I *think* if we were to increase our fuzz testing, we'd probably want to
> concentrate efforts there. Google also offer $ rewards to critical projects
> like Django for reaching certain levels of coverage, which is nice of them.
>
> Thanks,
>
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2%2Bbz%2BwVgiZiVG7YijwO0zzxZcfVE%3Dpxmcper7D3iUJQg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2%2Bbz%2BwVgiZiVG7YijwO0zzxZcfVE%3Dpxmcper7D3iUJQg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMRRKVe8uq3nVaukgW5iN3cBVnzFuQ4k7Fq4R99-U4DfRVWAXA%40mail.gmail.com.

Re: Property-based "fuzzy" testing (Hypothesis) in Django

[Elena Williams]

(Goodness, we're always reserved about our own work.) Yabbering further
with Zac having sent this email, it become evident I didn't include the
link to my personal guide for Hypothesis testing for Django Users that
started all this. It's er, quite different, from the official docs and
probably more friendly.

Threw it together earlier today, but I'm want to introduce why using these
is a good idea and also work towards provide a guide for converting
existing test suites:
https://github.com/elena/example-tests-django-hypothesis/

There's some gnarly json stuff in my own world that I'm going to be running
at and making examples of once it's nutted through. Of course all feedback
would be delightful.

There is also discussions with Zac and David about re-working the official
docs, but we're coming from epistemologically different places, so gently
gently.
---
Elena Williams
Github: elena <http://github.com/elena/>


On Fri, 21 Feb 2020 at 16:34, Elena Williams  wrote:

> Dear Django dev community,
>
> More and more of the python ecosystem is implementing property-based
> testing to find difficult and counter-intuitive edge cases using the
> library hypothesis:
> https://github.com/HypothesisWorks/hypothesis/tree/master/hypothesis-python
>
> For example testing using hypothesis has found bugs in the python language
> itself, apparently JSON and regex implementation is even more interesting
> than it seems it should be. Zac Hatfield-Dodds (https://github.com/Zac-HD)
> has been invited to talk about hypothesis at the language summit at PyCon
> this year and is again running a workshop about the library.
>
> The context of this email is that I've been working with Zac to try to
> make sense of Hypothesis in a Django user context. The current
> documentation for this is here if anyone is curious:
> https://hypothesis.readthedocs.io/en/latest/django.html ... honestly I
> think it's pretty opaque for a normal Django dev, though is very powerful
> and would replace nearly all the tests me and my friends have ever written,
> and moreover do a better job of it.
>
> As the conversation continued about how testing works in a django instance
> (turns out we use odd patterns and it's not how they thought it works) it
> became a giant question mark about if/how hypothesis testing would be
> implemented in the django framework itself.
>
> To briefly digress: he suggested I write an example for testing a straight
> model and I was baffled. This isn't something I've thought about for a long
> time but I did think about it once, my (potentially incorrect) belief is:
> ..  if I just made a vanilla django model with vanilla fields with no
> methods (no anything else whatsoever, say no views nor functions nor
> anything at all) it would be redundant for me to write any tests. They
> wouldn't do anything  -- there'd effectively be nothing to test. It would
> all have been brutally validated at the framework/database level.
>
> What I asserted to Zac is that I consider this the responsibility of the
> framework -- I mean if django field validation/saving is failing tests at
> the ORM level on an oracle db in a certain environment or something, that
> might be a case a test written for model would pick up, but I would never
> think this was a user concern. Sure if I do something exotic I'll write my
> own tests, but I ... profoundly trust the ORM to validate vanilla model
> fields. Maybe this is old thinking or I'm misguided, I'd be fascinated to
> hear what others think and to follow this thread to the end, but this is a
> digression.
>
> Suffice to say this does seem to point to somewhere that property-based
> testing would be appropriate at the framework level, not only at the user
> level.
>
> I'm writing because perhaps we could talk about django using "complex"
> testing like this, as there are areas for which it might be appropriate to
> improve the robustness of the framework. It's particularly useful for
> improving robustness on encoding edge-cases, which are a perenniel problem
> we care about.
>
> For example where data is being passed around it could perhaps be using
> "fuzzy" strategy, for example here (I think, though could be wrong):
> https://github.com/django/django/blob/master/django/test/client.py
>
> I was going to make a ticket, but then thought to just email the list to
> have a chat instead.
>
> All the very best to everyone and warm hellos to friends old and new,
> ---
> Elena Williams
> Github: elena <http://github.com/elena/>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMRRKVd2exTnVa_QE7X%2BdG_OFc24DfoWp1rutJKNBv4%2BCuksxQ%40mail.gmail.com.

Property-based "fuzzy" testing (Hypothesis) in Django

[Elena Williams]

Dear Django dev community,

More and more of the python ecosystem is implementing property-based
testing to find difficult and counter-intuitive edge cases using the
library hypothesis:
https://github.com/HypothesisWorks/hypothesis/tree/master/hypothesis-python

For example testing using hypothesis has found bugs in the python language
itself, apparently JSON and regex implementation is even more interesting
than it seems it should be. Zac Hatfield-Dodds (https://github.com/Zac-HD)
has been invited to talk about hypothesis at the language summit at PyCon
this year and is again running a workshop about the library.

The context of this email is that I've been working with Zac to try to make
sense of Hypothesis in a Django user context. The current documentation for
this is here if anyone is curious:
https://hypothesis.readthedocs.io/en/latest/django.html ... honestly I
think it's pretty opaque for a normal Django dev, though is very powerful
and would replace nearly all the tests me and my friends have ever written,
and moreover do a better job of it.

As the conversation continued about how testing works in a django instance
(turns out we use odd patterns and it's not how they thought it works) it
became a giant question mark about if/how hypothesis testing would be
implemented in the django framework itself.

To briefly digress: he suggested I write an example for testing a straight
model and I was baffled. This isn't something I've thought about for a long
time but I did think about it once, my (potentially incorrect) belief is:
..  if I just made a vanilla django model with vanilla fields with no
methods (no anything else whatsoever, say no views nor functions nor
anything at all) it would be redundant for me to write any tests. They
wouldn't do anything  -- there'd effectively be nothing to test. It would
all have been brutally validated at the framework/database level.

What I asserted to Zac is that I consider this the responsibility of the
framework -- I mean if django field validation/saving is failing tests at
the ORM level on an oracle db in a certain environment or something, that
might be a case a test written for model would pick up, but I would never
think this was a user concern. Sure if I do something exotic I'll write my
own tests, but I ... profoundly trust the ORM to validate vanilla model
fields. Maybe this is old thinking or I'm misguided, I'd be fascinated to
hear what others think and to follow this thread to the end, but this is a
digression.

Suffice to say this does seem to point to somewhere that property-based
testing would be appropriate at the framework level, not only at the user
level.

I'm writing because perhaps we could talk about django using "complex"
testing like this, as there are areas for which it might be appropriate to
improve the robustness of the framework. It's particularly useful for
improving robustness on encoding edge-cases, which are a perenniel problem
we care about.

For example where data is being passed around it could perhaps be using
"fuzzy" strategy, for example here (I think, though could be wrong):
https://github.com/django/django/blob/master/django/test/client.py

I was going to make a ticket, but then thought to just email the list to
have a chat instead.

All the very best to everyone and warm hellos to friends old and new,
---
Elena Williams
Github: elena <http://github.com/elena/>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMRRKVeiNJEzst6pQbsMKhodGdBZ%2BHmSFr4F0fukigGWFd33jA%40mail.gmail.com.

Re: Stalled tickets

[Elena Williams]

Interestingly there's an example of a long dead ticket rising 7-8 days ago:
https://code.djangoproject.com/ticket/14218

I believe this is an interesting reference for this conversation though not
sure if any side of the discussion is helped.

---
Elena Williams
Github: elena <http://github.com/elena/>


On Fri, 27 Sep 2019 at 19:32, Adam Johnson  wrote:

> I'm also not sure of the value of closing stalled tickets. Closing them
> makes them less visible, and as Claude says, they're still valid. Often I
> find one that's been open years has "come up again" on the mailing list or
> client work.
>
> The fellows are the ones who work the most with ticketing system, I've
> never heard any past or present fellow say that it would be a good idea to
> close open, valid tickets. They're also very good at closing tickets they
> believe are invalid.
>
> On Fri, 27 Sep 2019 at 08:08, Claude Paroz  wrote:
>
>> Sorry but I would *strongly* oppose any idea of closing a ticket because
>> noone commented in the last x years. Most of those tickets are still valid
>> issues, but they remain open because noone dedicated the appropriate time
>> to solve them, sometimes because the problem is a corner case, sometimes
>> because it would take considerable time to prepare a reviewable patch.
>>
>> I don't know what it would bring to the project to close those stalled
>> issues. I still hope that more people would dedicate some of their time
>> (free or paid) to "adopt" one of those tickets and make the effort to lead
>> them until resolution.
>>
>> You've been invited :-)
>>
>> Claude
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/e29a1c84-c37a-4f62-a763-c357c419126f%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/e29a1c84-c37a-4f62-a763-c357c419126f%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3Y_dSonAsiva8yg5TKPWAhU8Z-MTLkjga-KQ9cFtr2_A%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM3Y_dSonAsiva8yg5TKPWAhU8Z-MTLkjga-KQ9cFtr2_A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMRRKVfv02-6_zD%2B%3DgmGf_x_xnuzWuGb1e8%3DCtPBq%3D6ywUEhWw%40mail.gmail.com.

Re: Two proposals for the Django Code of Conduct.

[Elena Williams]

Additional points:

Firstly #86 is probably *already happening informally*.

It is fair to be "explicit" (as Barbara suggested), for the people who this
may effect.

For example, I have been quietly told to steer clear of certain individuals
with known poor behavior and in turn passed such information on to others
(this may be prejudicial, but sorry, there's no way I wouldn't do
everything I can to protect younger females in the community).

Secondly, most harassment *does not get reported* -- *if you think
otherwise please ask around*. Personally I'm so jaded, I'd probably never
report anything that didn't require being reported to the cops (despite
there having been colourful incidences, even in this community). When I was
in my early 20s I had the scarring experience of having been forced to
report workplace harassment (someone else observed) and it driving *me* out
of the job. And the rest. Besides even if I wanted to report something I
wouldn't really know how to and I'd be embarrassed, shy and undoubtedly
play it down.

Finally in my extremely personal opinion I'm .. skeptical about how
effective CoCs are at handing individual incidents *BUT* strong evidence
suggests a *correlation between CoC use and female attendance* -- *better
than anything else that's ever been attempted* and that's good enough for
me (to fight for).

---
Elena :)
@elequ

On Thu, Sep 11, 2014 at 10:11 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Thu, Sep 11, 2014 at 6:11 AM, Andrew Pinkham 
> wrote:
>
>> Hi,
>> I am not qualified enough to express an opinion on the matter of the
>> DCoC. However, I have a few questions:
>>
>> - Have we consulted a psychologist or a specialist on the topics of
>> community inclusion and protection? Their knowledge/research could be
>> instrumental in determining the best way to write and implement a code of
>> conduct.
>>
>
> Yes. The original draft text came from the "Speak Up" project; the Ada
> Initiative - a specialist group dealing with inclusivity and engagement of
> women in technical spaces - was consulted during the drafting process, and
> their suggestions (such as specifically enumerating infringing behaviours)
> were incorporated into the text.
>
> - Am I correct in assuming that the sole aforementioned invocation of the
>> DCoC was the following?
>> https://groups.google.com/d/msg/django-developers/Y_Tq7w4PAeI/WurT7J3Rcd0J
>
>
>
>> - Would it be correct to state that, with or without this wording, the
>> results of breaking the DCoC would be identical? Is it correct to say that
>> the new wording is for the benefit of being clear and open, such that new
>> members better understand the rules?
>>
>
> I believe so. One of the issues that has been referred to the Code of
> Conduct committee was specifically about activities outside "official"
> Django spaces. These changes serve to clarify the fact that we don't turn a
> blind eye to infringing activities just because they weren't conducted "on
> our turf".
>
> - These rules have been referred to several times as guidelines to adhere
>> to. Would it be in the interest of the community to say as much on the DCoC
>> webpage (rather than or alongside "rules")?
>>
>
> The current text (https://www.djangoproject.com/conduct/) does say
> something to this effect; specifically, Paragraph 3: "This isn’t an
> exhaustive list of things that you can’t do. Rather, take it in the spirit
> in which it’s intended - a guide to make it easier to enrich all of us and
> the technical communities in which we participate."
>
> Of course, P2 also refers to the document as being a set of "rules".
> Altering P2 (or the updated location as a result of PR#84) to say "This
> code" rather than "these rules" makes sense to me.
>
> Yours,
> Russ Magee %-)
>
>  --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq849RRirywtER1kvb8twstTif%2BQ59oWELgSBSnL7%3DuARDxA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this 

Re: pre_save signal on Inherited Model?

[Elena Williams]

Hi Leo,

This is the django-developers mailing list for discussing the development 
of Django itself. 

For questions about using Django or Django-based applications, please 
instead post your question to the django-users mailing list: 
http://groups.google.com/d/forum/django-users

All the best,
Elena

On Wednesday, August 20, 2014 8:48:07 AM UTC+8, Leo Hillman wrote:
>
> I just wanted to write a preliminary post about this before gathering a 
> little more data. When extending a non-abstract model (Python inheritance) 
> it seems to me that a pre_delete signal registered to the parent model is 
> fired when an inherited model is deleted—which would be expected. A 
> pre_save signal registered to the parent model, however, does not seem to 
> be firing when saving the inherited model. I am not sure if this is desired 
> behavior, but it is slightly confusing.
>
> — pre_delete registered on parent model: fired
> — pre_save registered on parent model: not fired
>
> I came upon this case when extending the djcelery PeriodicTask object. 
> When creating an instance of an inheriting model, the pre_save signal was 
> not sent, but the pre_delete signal did seem to be sent.
>
> Any thoughts? I can get around this by manually registering the inheriting 
> model.
>
> aryeh
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2a8d46de-4497-4068-a333-a2b1ce8a9ead%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

The low down on the "Unsettings" project

[Elena Williams]

Hello, 

Just sending general heads up that this bit of knowledge exists, but this 
is Justin Myles Holmes talking about the "unsettings" project, that is the 
idea of removing `settings.py`.

https://soundcloud.com/elena/django-news-podcast-18-may-2014#t=7m33s

This is actually a really interesting explanation about why this matters. 
It changed the way I thought about it.

Quote: "this is an effort to transform Django from being .. frankly an 
Apache plug-in .. to a python library, or really a series of python 
libraries ..." etc.

He talks about some really principles behind Django generally and 
holistically and the implications of changing the way settings are and 
actually what Django is all about in a sense. 

Thank you to everyone so much!
Elena :)
@elequ

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/db931ede-0b01-4f6b-a8c1-c1e203b29316%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Release of 1.7 news for podcast?

[Elena Williams]

Thank you thank you!

It's a massive release so I for one would much rather be sure and confident 
than rushed.

Thank you Tim and Andrew, and take care (I would recommend sunshine and 
sandy beaches ... bt ... )

Elena :)
@elequ

On Monday, May 19, 2014 4:57:59 AM UTC+8, Andrew Godwin wrote:
>
> Given that I'm still abroad at this point, I'm not as productive as I can 
> be at the moment for health reasons, and the number of release blockers 
> seems to keep growing, I wouldn't be able to put on a date on it. At least 
> a month at this point I suspect, but hopefully sooner.
>
> Andrew
>
>
> On Sun, May 18, 2014 at 6:11 PM, Tim Graham <timog...@gmail.com
> > wrote:
>
>> You can use this link to see the current list of release blockers for 1.7:
>>
>>
>> https://code.djangoproject.com/query?status=assigned=new=!master=Release+blocker=id=summary=status=owner=type=component=changetime=1=changetime
>>
>> I would guesstimate we're at least a month out from 1.7 final since 
>> there's a minimum of 2 weeks after a release candidate is issued before 
>> final.
>>
>> Andrew may have some more concrete thoughts on how long the migrations 
>> release blockers might take to resolve.
>>
>>
>> On Saturday, May 17, 2014 11:29:38 PM UTC-4, Elena Williams wrote:
>>>
>>> (Don't want to pester anyone but ... )
>>>
>>> I was wondering if there's any updates about where the Django 1.7 
>>> release is at that I can put in to the podcast?
>>>
>>> Thanks!
>>> Elena :)
>>> @elequ
>>>
>>> ---
>>> References (nothing new on these):
>>> Roadmap: https://code.djangoproject.com/wiki/Version1.7Roadmap
>>> Release notes: https://docs.djangoproject.com/en/dev/releases/1.7/
>>>
>>  -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/e77d9800-bb57-4f4b-89aa-36d4c5eb6f6b%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/e77d9800-bb57-4f4b-89aa-36d4c5eb6f6b%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/07818b0d-3b26-4353-94a3-99625553474c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Release of 1.7 news for podcast?

[Elena Williams]

(Don't want to pester anyone but ... )

I was wondering if there's any updates about where the Django 1.7 release 
is at that I can put in to the podcast?

Thanks!
Elena :)
@elequ

---
References (nothing new on these):
Roadmap: https://code.djangoproject.com/wiki/Version1.7Roadmap
Release notes: https://docs.djangoproject.com/en/dev/releases/1.7/

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/91e58b77-f9c9-4d29-982e-e8f7d472e2a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

[Elena Williams]

Dear Florian,

Thanks so much for your update/feedback.

I updated the update 
here: https://github.com/elena/django-news-podcast/issues/1

Thanks again!
Elena


On Sunday, December 29, 2013 8:10:30 PM UTC+11, Florian Apolloner wrote:
>
> Just so we are all on the same page here (summarizing discussions from IRC 
> etc):
>
>  * We are not going to support setuptools and distutils, this makes the 
> setupprocess difficult to debug and test imo.
>  * Given Donald's "okay" we might switch to setuptools completely 
>  * There seems to be a bug in pip when installing a wheel, which renders 
> the django-admin.exe unusable on windows, help welcome
>  * PR for this issue is now at: 
> https://github.com/django/django/pull/2116[The original didn't work at all]
>
> Cheers,
> Florian
>
> On Sunday, November 24, 2013 7:18:15 PM UTC+1, Remram wrote:
>>
>> Hi developers, 
>>
>> On Windows, running the django-admin.py tool is painful[1], because 
>> .py scripts are not "executable". You might be able to run it using 
>> the full path (if Python is the default handler for .py files, which 
>> it really shouldn't be). Most probably you'll need to copy it to your 
>> project directory and prefix it with "python " each time. 
>>
>> setuptools has a neat workaround for scripts on Windows, which works 
>> great: it creates a wrapper binary that it puts on the PATH. I know 
>> from previous threads that Django chose to move away from setuptools 
>> and back to distutils, however it is easy to conditionally use this 
>> feature if setuptools are available. That way, Windows developers that 
>> have setuptools installed (which should be, like, all of them) will be 
>> able to run django-admin.py easily. 
>>
>> I submitted a pull request on Github[2] a month ago, then opened a 
>> ticket[3] later on. Apart from an uncommented update from akaariai, I 
>> didn't get any feedback. 
>>
>> I'd really like to see this small change accepted. It is fairly minor 
>> but would work towards restoring the portability that is a strength or 
>> Python. 
>>
>> Thanks for your input/reviews/time, 
>> -- Remram 
>>
>> [1] http://stackoverflow.com/q/19593404/711380 
>> [2] https://github.com/django/django/pull/1812 
>> [3] https://code.djangoproject.com/ticket/21340 
>>
>> TL;DR: what happened to my patch? 
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3050acc2-266f-4d9b-a9b7-f9043dd46664%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal of (another) podcast

[Elena Williams]

Merry Festive season to everyone to whom this is relevant!

tl;dr:
- News Podcast: basically reading blog out loud, hopefully short: ~15mins 
- Aiming for 30-Dec recording/publishing
- Seeking review of script/show 
notes<https://github.com/elena/django-news-podcast/blob/master/_2013-12-29.md>
 for 
the 30-Dec recording
- Seeking file hosting suggestions

In light of the recent new update email (thanks Curtis!) and apparent 
recent discussions about dispersing news and information, I'm interested in 
doing a new kind of Django podcast.

This project is intended to target the members of the community who receive 
their news via podcasts -- to complement the blog, update email, 
announcements list, twitter, etc.

The aim is to be as *short* and *content rich* as possible within reason. 
My intended format is:

0. Security Advisories
> 1. Upcoming Cut-off Dates
> 2. Releases and Release Notes
> 3. Conferences/Events
> 4. General News
> 5. Community Requests
> (+ Django Dev email list summary)
> (+ Interview with core)


I have mainly prepared the content I'd intend to record and publish on 
30-Dec:
https://github.com/elena/django-news-podcast/blob/master/_2013-12-29.md
Patches are most welcome for any corrections or additions! Obviously this 
is my first attempt at this.

After talking to Curtis Maloney (aka FunkyBob) I'd intend to sync with 
every second email update, the 29/30 December will coincide with that.

A while ago I did an outline of a proposed format, which I've discussed 
with a few people including Curtis and Russell Keith-Magee: 
https://github.com/elena/django-news-podcast

To summarise: the format is basically *reading out loud the emails* (as was 
gracefully deduced by Russ).

The intention is to be short, say ~15 minutes for the main content and 
additional/bonus content going on for no longer than 30-45 minutes.

---

I'm wary that having seen the podcasts come and go that it's obviously 
tedious and/or boring and/or problematic in some way as they have tended to 
expire. This particular factor has been something I've given a lot of 
consideration to before sending this email.

My solution to this apparent pitfall is to attempt to make it as communal, 
modular and simple as possible -- with a rigid "fill-in-the-blanks" format, 
thus easily handed around for multiple people to do, should whatever 
happens to the other podcasts, happen to me.

At this stage (it's been on my mind for so long) I'm willing to champion 
this for as long as I can, though if anyone is interested in helping out 
with helping with any part of this project, eg, preparation, interviews, 
recording, editing, other segments, journalism/recording advice,  I'll 
welcome it enthusiastically!

I'm concerned about posting erroneous information, but I think that this is 
unavoidable and hopefully by making the script/show notes open to patches 
this will be a tractable problem.

--

Ideally I'd love to add *interviews* to the format.

For example it seems as though it would have been great to have a chat with 
Aymeric during this time as he's been doing a lot of work and to have him 
summarise this in his own words would be informative, though perhaps I'll 
be able to chase him up in the new year when I have real internet back 
again.

Also it feels like too much to attempt: doing an interview for this first 
edition (which I intend to record tomorrow). I've been travelling during 
this time and my internet has been appallingly (un-skype-ably) bad and it's 
also too much pressure at this early stage. 

--
 
I may still get it all wrong and don't promise anything will come of this 
suggestion, though have gotten to the stage where I feel confident enough 
to approach this list.

Essentially this is my own itch -- I'm motivated to scratch it and it seems 
like a bit of fun.

My final dilemma is where to make the podcast available from (in a hosting 
sense), but as I don't know the final file size yet I haven't agonised 
about this. I have plenty of options -- though any advice would be 
sincerely appreciated.

Any feedback at all would be sincerely appreciated actually! 
---
Elena Williams
@elequ

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ddc13c72-a45e-4083-b242-c90b36024ae3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.