Re: Ready for checkin

[Josh Smeaton]

I see what you're saying Daniele, I had to ask about the terminology only a 
couple of weeks ago. Hopefully I can provide some clarity.

Ready For Check-in means that someone other than the author has reviewed 
the patch and believes it is ready to be merged. However, the patch must 
also be reviewed by a core team member before it can be merged. So really, 
you need context for the Ready For Check-in status. If a core contributor 
marked it as such, it really is ready to be merged. Otherwise, it still 
needs reviewing.

If a core contributor believes a patch can be merged though, they could 
just push the big green button. I *think* the status is only really useful 
for signalling to the core team that the patch should be reviewed. Even 
though the name is somewhat confusing, I don't think there is a need to 
change it. The person changing the status to RFC believes the patch is 
ready, but a core member can change it back after review. The name should 
be consistent though.

Josh

On Tuesday, 17 June 2014 12:54:44 UTC+10, Daniele Procida wrote:
>
> On Mon, Jun 16, 2014, Greg Chapple  
> wrote: 
>
> >Would "Ready for merge" not be a more appropriate term? 
>
> Well no - because it isn't ready for merge. It may well be far from ready. 
> Ironically "ready for checking" is closer to the intended meaning. 
>
> Daniele 
>
>

-- 
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/f1aee68c-84c8-465f-b74a-c0f332bc473d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ready for checkin

[Daniele Procida]

On Mon, Jun 16, 2014, Greg Chapple  wrote:

>Would "Ready for merge" not be a more appropriate term? 

Well no - because it isn't ready for merge. It may well be far from ready. 
Ironically "ready for checking" is closer to the intended meaning.

Daniele

-- 
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/20140616221046.263782193%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Ready for checkin

[Russell Keith-Magee]

+1 to Ready For Commit.

Russ %-)

On Tue, Jun 17, 2014 at 7:14 AM, Marc Tamlyn  wrote:

> If check in is SVN how about RFC meaning ready for commit?
> On Monday 16 June 2014 20:09:13 Greg Chapple wrote:
> > Would "Ready for merge" not be a more appropriate term? To me, check-in
> is
> > a term I would associate with SVN.
> >
>
> Yes, except that RFM sounds more like "Read Forgotten Manual" :)
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/201406162019.37543.shai%40platonix.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 discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1Ff%2B%3DKnHG%3D%2BQo01VMhhSHOY882fjTVVVa3mngg4NXg%3DOg%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 discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq8491Rvr6vDHLwm85TG9o18OYcNUq%2Bmqoja%2BVrLDxn8tG-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ready for checkin

[Marc Tamlyn]

If check in is SVN how about RFC meaning ready for commit?
On Monday 16 June 2014 20:09:13 Greg Chapple wrote:
> Would "Ready for merge" not be a more appropriate term? To me, check-in is
> a term I would associate with SVN.
>

Yes, except that RFM sounds more like "Read Forgotten Manual" :)

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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/201406162019.37543.shai%40platonix.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 discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Ff%2B%3DKnHG%3D%2BQo01VMhhSHOY882fjTVVVa3mngg4NXg%3DOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ready for checkin

[Greg Chapple]

Would "Ready for merge" not be a more appropriate term? To me, check-in is
a term I would associate with SVN.

- Greg
On 16 Jun 2014 18:06, "Tim Graham"  wrote:

> +1 to "check-in"
>
> On Monday, June 16, 2014 12:08:43 PM UTC-4, Daniele Procida wrote:
>>
>> "Ready For Check-in" appears in the docs once; "Ready for Checkin"
>> appears five times, and on Trac.
>>
>> Can we change it universally to "Ready for check-in"? Or better "Ready
>> for core team review"?
>>
>> What's wrong with "checkin":
>>
>> * it's incorrect
>> * I've more than once read it and imagined it must be a mispelling of
>> "checking"
>> * it looks like it might be the name of a town in the Balkans
>>
>> But also it's not immediately obvious what "checkin" (or indeed
>> "check-in") means; it sounds like it might involve formally accepting
>> something into the system, and so I'd actually prefer something like "Ready
>> for core team review".
>>
>> Daniele
>>
>>  --
> 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/8dad3051-e4f7-4b3e-9078-2ce45b4f1887%40googlegroups.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 discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKF68RHkP%2BmjQHDaGQwgr%3DoW%3Dsg6DT35BWgyoFkC9rUjV6eDMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ready for checkin

[Shai Berger]

On Monday 16 June 2014 20:09:13 Greg Chapple wrote:
> Would "Ready for merge" not be a more appropriate term? To me, check-in is
> a term I would associate with SVN.
> 

Yes, except that RFM sounds more like "Read Forgotten Manual" :)

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201406162019.37543.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ready for checkin

[Tim Graham]

+1 to "check-in"

On Monday, June 16, 2014 12:08:43 PM UTC-4, Daniele Procida wrote:
>
> "Ready For Check-in" appears in the docs once; "Ready for Checkin" appears 
> five times, and on Trac. 
>
> Can we change it universally to "Ready for check-in"? Or better "Ready for 
> core team review"? 
>
> What's wrong with "checkin": 
>
> * it's incorrect 
> * I've more than once read it and imagined it must be a mispelling of 
> "checking" 
> * it looks like it might be the name of a town in the Balkans 
>
> But also it's not immediately obvious what "checkin" (or indeed 
> "check-in") means; it sounds like it might involve formally accepting 
> something into the system, and so I'd actually prefer something like "Ready 
> for core team review". 
>
> Daniele 
>
>

-- 
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/8dad3051-e4f7-4b3e-9078-2ce45b4f1887%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ready for checkin

[Daniele Procida]

"Ready For Check-in" appears in the docs once; "Ready for Checkin" appears five 
times, and on Trac.

Can we change it universally to "Ready for check-in"? Or better "Ready for core 
team review"?

What's wrong with "checkin":

* it's incorrect
* I've more than once read it and imagined it must be a mispelling of "checking"
* it looks like it might be the name of a town in the Balkans

But also it's not immediately obvious what "checkin" (or indeed "check-in") 
means; it sounds like it might involve formally accepting something into the 
system, and so I'd actually prefer something like "Ready for core team review".

Daniele

-- 
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/20140616160827.428367890%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Add an extra parameter to 'static' tag

[Shai Berger]

Hi Renato,

Sorry for being a little late to this party.

On Sunday 01 June 2014 17:36:43 Renato Oliveira wrote:
> 
> Yeah, i'm aware of this, and sorry for not being explicit. The goal of this
> improvement is to point to many places. For exampe, if I have a project
> with, bootstrap, jquery and angular. I can do this:
> 
> {% static 'path/to/my/angular.js' http://googlecdn/angular.js %}
> {% static 'path/to/bootstrap.css' http://bootstrapcdn/bootstrap.css %}
> 
> And If I have to write some css or js file,
> 
> {% static 'path/to/users.js' %}
> 
> And this would use Django storage or S3, whatever.

I suspect that your proposal could be acceptable, if, instead of adding HTTP 
sources into the templates, you added a "using=" argument that referenced a 
file-storage object -- similar to the one on the cache tag.

The problem with this idea is that, while caches are named in a settings 
entry, there is currently no such "registry" of file-storage objects. One could 
arguably be added to staticfiles' AppConfig, but that will probably only happen 
if there are more uses for named storages.

Anyway, doing it this way addresses Florian's concerns -- control of which 
named storage goes where stays at the project level, the templates only 
specify grouping of files; and I think it gives most of what you want. 

The only concern I have about it is, it may be over-engineered -- in practice, 
you don't usually have whole sets of files in different storages, and if you 
do, 
you can probably tell the right storage by path; so a simpler solution is a 
custom storage (as Florian pointed) which makes all the decisions.

YMMV,
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201406161812.34475.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Time to drop support for Oracle < 11?

[Reinout van Rees]

On 14-06-14 02:52, Tim Graham wrote:

11.1 - Aug 2007 - Aug 2012 - Aug 2015
10.2 - Jul 2005 - Jul 2010 - Jul 2013


To provide an additional data point: I checked with a colleague. We do a 
lot of business with governmental organizations in the Netherlands 
(mainly water boards). Most of them are on 11. With one or two still 
migrating from 10... :-)



Reinout

--
Reinout van Rees  http://reinout.vanrees.org/
rein...@vanrees.org   http://www.nelen-schuurmans.nl/
"Learning history by destroying artifacts is a time-honored atrocity"

--
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/lnmlbk%24qam%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: Time to drop support for Oracle < 11?

[Marc Tamlyn]

There will be a need for some gradiented support of Psql with
contrib.postgres. I think a sensible CI setup would be to run the full test
suite against 9.4 and the contrib.postgres test suite only against 9.1-9.3.
That would be my preferred compromise.

Marc
On 16 Jun 2014 01:24, "Russell Keith-Magee"  wrote:

>
> On Sun, Jun 15, 2014 at 11:49 PM, Hannu Krosing  wrote:
>
>>  On 06/14/2014 02:40 PM, Tim Graham wrote:
>>
>> It seems to weird to claim (even best-effort/community) support for a
>> database that is no longer supported by its authors. Also, you can always
>> use an older version of Django, right? I tend to think you're probably not
>> interested in the latest and greatest Django if you're using a really old
>> database. My general proposal (for all databases) would be to drop support
>> for a database version in the Django release that follows its end-of-life
>> date.
>>
>> Regarding testing, Oracle is currently not on CI, but Shai and I are
>> working to add support for 11 and 12. This would actually be the only
>> database where we have testing for multiple versions. For the other
>> databases we are using whatever version Ubuntu 12.04 ships with (PostgreSQL
>> 9.1.13, MySQL 5.5.37).
>>
>>
>> Heh, The "whatever version Ubuntu 12.04 ships with" test policy seems
>> kind of weird (especially if this is meant to go on forever :) )
>>
>
> It's an arbitrary version selection of an old(ish) commonly used Linux
> distribution.
>
> In an ideal world: Yes, we'd test against every major distro, and every
> major Postgres version installed on that distro, and so on; but we have
> limited resources (including the patience to make and configure build boxes
> as one of those resources :-)
>
> At some point in the future, long before EOL of Ubuntu 12.04, we'll
> probably upgrade the build boxes to 14.04. I'm guessing the introduction of
> Marc's PostgreSQL-specific features from his Kickstarter might be the
> stimulus for this.
>
>
>> According to http://www.postgresql.org/support/versioning/ PostgreSQL
>> 9.1 was released 2.5 years ago and is in the middle of its 5 year life
>> cycle which ends in September 2016.
>>
>> PostgreSQL 9.1 also lacks lots of newer stuff.
>>
>> Thanks to ubuntu/debian pg_createcluster  and friends it is actually easy
>> to run multiple versions of postgresql (I have everything from 8.4 to
>> latest 9.4 beta running in parallel on my laptop), so my suggestion would
>> be at least for postgresql to
>>
>> a) add pgdg repo to ubuntu (
>> http://www.postgresql.org/download/linux/ubuntu/ )
>> b) test with all versions supported by pgdg
>>
>
> Yes, this is possible; the question is whether this is a valuable use of
> our limited resources. I can only think of a handful of occasions in
> Django's 8 year public history where SQL-handling behaviour in PostgreSQL
> has changed in a way that required testing multiple versions - and most of
> those occasions were in the 7.X-8.X transition. Django's usage of SQL is
> fairly conservative; the areas where PostgreSQL is add features aren't the
> areas where Django treads, generally. As a result, there is a reduced
> imperative to test all these versions.
>
> This will of course change when we start supporting PostgreSQL-specific
> features, so we'll probably have to revisit this - but even then, I suspect
> testing an old version (e.g., 9.1) and a recent version (e.g., 9.4) will
> probably give us sufficient confidence that the build is working.
>
> 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/CAJxq849rV6pu_gX9JaCKOHxj%2BFU9p9U3ii%2BA54VHjF7WncT5Gw%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 discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FL%2ByUGWVgOL0BrjZDOODs%3DDpmD8_FYV%2B2PNi0WwV4KFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.