Re: Vote on Jira as bugtracker

[Tim Graham]

To search Trac, use "site:code.djangoproject.com your query" in a Google 
search box. Works great in my experience.

On Wednesday, January 6, 2016 at 6:42:44 PM UTC-5, Josh Smeaton wrote:
>
> FWIW I actually like Jira (much more than Trac) and find it a lot easier 
> to use. I think the trick is configuring very basic workflows so users 
> don't have to fight through transitions. Open, Closed, Assigned/In Progress 
> and transitions to and from each state would get us really close to the 
> current Trac workflow. My number 1 gripe with Trac is that search SUCKS, so 
> I'd actually be in favour of a migration *if someone else were to do all 
> the work* :D. But that's the rub isn't it, nothing comes for free. We'd 
> also lose login with Github (I think) and psuedo-anonymous triage because 
> Jira requires an email account, so there's no way it could be a full parity 
> transition.
>
> Taiga looks very nice, but arguments made above also apply. There's a cost 
> in setup + migration, overhead of learning a new system, and a lack of 
> knowledge about the problems that will evidently exist.
>
> I really do think Trac is awful though, just wanted to be clear about that.
>
> On Thursday, 7 January 2016 03:34:13 UTC+11, Victor Sosa wrote:
>>
>>
>> Looks like it is a NO to the proposition.
>>
>> Daniele
>>
>> I like what I saw in taiga, that's a way better bug tracking UI; you can 
>> check here:
>>
>> https://tree.taiga.io/project/taiga/issues?page=1
>>
>> On Wednesday, January 6, 2016 at 12:18:13 PM UTC-4, Daniele Procida wrote:
>>>
>>> On Wed, Jan 6, 2016, Daniele Procida  wrote: 
>>>
>>> >By all means it's useful to get votes on something like this, even 
>>> >before we consider those questions, because if enough people want 
>>> >something it's always possible - but be aware that simply getting lots 
>>> >of votes for it would only ever be the first and easiest step. 
>>>
>>> While we're in the realm of the completely hypothetical, if I were going 
>>> to find myself enthusiastic about moving to a new development tracking 
>>> platform, it would be Taiga.  
>>>
>>> It's written in Django, by a company that actively supports the Django 
>>> community. It's open-source.  The people who develop it are approachable 
>>> and friendly. It has a nice name. 
>>>
>>> Daniele 
>>>
>>>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/abcb543e-c8fd-4e7e-ae8f-f8c3e8de99ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Josh Smeaton]

FWIW I actually like Jira (much more than Trac) and find it a lot easier to 
use. I think the trick is configuring very basic workflows so users don't 
have to fight through transitions. Open, Closed, Assigned/In Progress and 
transitions to and from each state would get us really close to the current 
Trac workflow. My number 1 gripe with Trac is that search SUCKS, so I'd 
actually be in favour of a migration *if someone else were to do all the 
work* :D. But that's the rub isn't it, nothing comes for free. We'd also 
lose login with Github (I think) and psuedo-anonymous triage because Jira 
requires an email account, so there's no way it could be a full parity 
transition.

Taiga looks very nice, but arguments made above also apply. There's a cost 
in setup + migration, overhead of learning a new system, and a lack of 
knowledge about the problems that will evidently exist.

I really do think Trac is awful though, just wanted to be clear about that.

On Thursday, 7 January 2016 03:34:13 UTC+11, Victor Sosa wrote:
>
>
> Looks like it is a NO to the proposition.
>
> Daniele
>
> I like what I saw in taiga, that's a way better bug tracking UI; you can 
> check here:
>
> https://tree.taiga.io/project/taiga/issues?page=1
>
> On Wednesday, January 6, 2016 at 12:18:13 PM UTC-4, Daniele Procida wrote:
>>
>> On Wed, Jan 6, 2016, Daniele Procida  wrote: 
>>
>> >By all means it's useful to get votes on something like this, even 
>> >before we consider those questions, because if enough people want 
>> >something it's always possible - but be aware that simply getting lots 
>> >of votes for it would only ever be the first and easiest step. 
>>
>> While we're in the realm of the completely hypothetical, if I were going 
>> to find myself enthusiastic about moving to a new development tracking 
>> platform, it would be Taiga.  
>>
>> It's written in Django, by a company that actively supports the Django 
>> community. It's open-source.  The people who develop it are approachable 
>> and friendly. It has a nice name. 
>>
>> Daniele 
>>
>>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a3fba94b-5896-462b-bcd0-f9985be26934%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Off topic] Re: Extending JSONField serialization

[Shai Berger]

Pet peeve: Please ignore if you don't care about database technologies.

On Wednesday 06 January 2016 17:12:34 Dwight Gunning wrote:
> design models that are a hybrid of our traditional, schema-oriented
> approach, but also include a JSON Field and offer the benefits of the more
> recent schemaless/nosql approach.
> 

Actually, nosql brought new ideas in terms of database distribution; as far as 
data management goes, the whole schemaless movement is one big regression. The 
"more recent" approach is, in fact, older, and the Relational Model was mostly 
a solution to its problems.

Shai.

Re: 1.8 shipping invalid .py files in the startapp template

[Claude Paroz]

Le mercredi 6 janvier 2016 19:34:07 UTC+1, Tim Graham a écrit :
>
> The current pull request proposes to make a backwards-incompatible change 
> by chopping off any ".tpl" suffix in app or project template files. i.e. 
> "If you are using custom templates and these templates already use a 
> ``.tpl``  suffix, you will need to append an additional ``.tpl`` (ie. 
> ``filename.tpl.tpl``)".
>
> Do you find this change acceptable in a minor release (1.9.2)? If not, we 
> could possibly limit the behavior to the templates in "django/conf".
>
> https://github.com/django/django/pull/5735
>

What about limiting chopping to ".py.tpl" => ".py"?

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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/89b0bf06-ca2f-459a-b327-c1ed30317725%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.8 shipping invalid .py files in the startapp template

[Tim Graham]

The current pull request proposes to make a backwards-incompatible change 
by chopping off any ".tpl" suffix in app or project template files. i.e. 
"If you are using custom templates and these templates already use a 
``.tpl``  suffix, you will need to append an additional ``.tpl`` (ie. 
``filename.tpl.tpl``)".

Do you find this change acceptable in a minor release (1.9.2)? If not, we 
could possibly limit the behavior to the templates in "django/conf".

https://github.com/django/django/pull/5735

On Monday, December 21, 2015 at 2:14:00 PM UTC-5, Carl Johnson wrote:
>
> FWIW, this also bit me. I have a deploy script that runs python -m 
> compileall as part of its build process. It was pretty easy to work around 
> by adding -x app_template, but why make everyone else work around Django? 
> ISTM it would be better to call the files .py_template instead since they 
> aren't valid Python.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9047e152-91bd-4bff-b6f5-2fa64670e7ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending JSONField serialization

[Raphaël Barrois]

On Wed, 6 Jan 2016 10:27:01 -0500
Michael Manfre  wrote:

> On Wed, Jan 6, 2016 at 9:58 AM, Tom Christie  wrote:
> 
> > Customizing the encoder (or even using DjangoJSONEncoder by default) isn't
> > so bad.
> >
> > I'm less convinced about the usefulness of customizing the decoder - once
> > you've encoded the data into JSON any additional type information is lost,
> > so casting back to python primitives is always going to need to be handled
> > explicitly.
> >
> 
> Whether or not a configurable decoder seems useful for the situations we
> can think of, only allowing users to configure half of the encode/decode
> cycle seems odd to me. Allowing both to be configurable requires a trivial
> amount of extra effort to implement and maintain.
> 
> Regards,
> Michael Manfre
> 

Indeed, this is only helpful if the user is able to customize both encoding and 
decoding of its messages.
For instance, on one of our projects, we use a custom serializer that encodes 
complex types as {"__type__": "foo", "value": "bar"} dicts.
Our deserializer can then handle the decoding of such fields to a native Python 
datastructure.

This is possible with "jsonfield" (https://pypi.python.org/pypi/jsonfield) 
which allows to set a custom encoder/decoder.

Coming back to Aymeric's question, I'd love to be able to set a custom 
decoder/encoder for a JSONField.
Being able to only specify the encoding is error-prone, since my code will then 
have to handle the distinction
between "this is a value set pre-save, so it's in a native type" and "this 
time, it's from the database, so I have to cast it back".


Regards,

-- 
Raphaël Barrois

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20160106173748.43400622%40ithor.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Victor Sosa]

Looks like it is a NO to the proposition.

Daniele

I like what I saw in taiga, that's a way better bug tracking UI; you can 
check here:

https://tree.taiga.io/project/taiga/issues?page=1

On Wednesday, January 6, 2016 at 12:18:13 PM UTC-4, Daniele Procida wrote:
>
> On Wed, Jan 6, 2016, Daniele Procida  
> wrote: 
>
> >By all means it's useful to get votes on something like this, even 
> >before we consider those questions, because if enough people want 
> >something it's always possible - but be aware that simply getting lots 
> >of votes for it would only ever be the first and easiest step. 
>
> While we're in the realm of the completely hypothetical, if I were going 
> to find myself enthusiastic about moving to a new development tracking 
> platform, it would be Taiga.  
>
> It's written in Django, by a company that actively supports the Django 
> community. It's open-source.  The people who develop it are approachable 
> and friendly. It has a nice name. 
>
> Daniele 
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/30f5154f-3261-496e-8af8-2a214fb38e10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending JSONField serialization

[Dwight Gunning]

Aymeric, thanks for clarifying. I take your point for joins although I'm a
bit surprised you don't feel JSONFields are appropriate for filtering.

I haven't tried yet but I am interested in the ability to efficiently index
into the JSONField (thanks to use of Postgres' jsonb fields). That is, to
design models that are a hybrid of our traditional, schema-oriented
approach, but also include a JSON Field and offer the benefits of the more
recent schemaless/nosql approach.

Sorry if that's all a bit off topic for the django-dev list. Happy to
switch over to django-users if that's more appropriate.

Dwight

--
Dwight Gunning
Twitter me: @dwightgunning 

On 6 January 2016 at 15:27, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello Dwight,
>
> I was trying to express the fact that JSONField is appropriate for storing
> data that won’t be used for joining other tables, filtering, aggregating,
> etc. but rather just for reading.
>
> “Not mission-critical” was a simplification. That said, data that meets
> the criteria above tends not to be the most important data in an
> application.
>
> In your example, at worst, if your app fails to read what it wrote
> previously to the JSON field, the user will just have to set their
> preferences again.
>
> --
> Aymeric.
>
> On 6 janv. 2016, at 12:33, Dwight Gunning 
> wrote:
>
> It's interesting that you say JSON Fields shouldn't be used for mission
> critical data. Is that widely recognised?
>
> I feel like there are genuine uses cases for using JSON Fields to store
> mission critical data. For instance, a Javascript single-page-app style
> client with a set of user preferences to adjust the UI look and feel. These
> preferences need to be persisted between sessions but don't really need to
> be normalised or separated into individual fields by Django, aside from
> perhaps light validation.
>
> Datetime encoding/decoding to integrate with third party systems is a
> regular headache for me. I typically writ DRF serializers to take care of
> datetime formatting, but a more general solution closer to the data layer
> would be nice.
>
> Regards,
>
> Dwight
> --
>
> On Tuesday, January 5, 2016 at 6:49:16 PM UTC+1, Aymeric Augustin wrote:
>>
>> > On 5 janv. 2016, at 18:37, Tom Christie  wrote:
>> >
>> >> Should JSONField accept additional kwargs to customize the encoder and
>> the decoder?
>> >
>> > Quick take here:
>> >
>> > That sounds like a bit too much "cleverness" to me. The most obvious
>> issue it'd cause is putting values of one type into the field, but getting
>> objects of a different type back. (eg datetime getting coerced into a
>> string on the way in, and left as a string on the way out).
>>
>> Yes, I understand how that could surprise a developer.
>>
>> A smart deserializer that would attempt to convert some strings back to
>> their original type, based on their content, would create the opposite
>> risk: a string that matches the format of a date could be accidentally
>> returned as a date.
>>
>> I wouldn’t do this for mission-critical data — but then I wouldn’t store
>> it in a JSON field either. Django projects should only use a JSON field for
>> data that isn’t worth normalizing into actual fields. Writing a schema to
>> map keys to types defeats the point; if you’re writing a schema, just
>> express it with traditional model fields.
>>
>> I don’t think Django should (de)serialize non-native JSON types by
>> default, but it should make it possible through public APIs, as this is a
>> common requirement. For my use case, logging, the convenience of being able
>> to store dates, datetimes and decimals without resorting the heavy guns
>> (DRF serializers) helps a lot.
>>
>> --
>> Aymeric.
>>
>
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a2868ea8-c559-4240-aaba-dbf1f6efbe64%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/upg9pgGvaUs/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> 

Re: got glossarium?

[Doug Epling]

For the third and final time, I appologize.


On Tuesday, January 5, 2016 at 11:50:51 AM UTC-5, Doug Epling wrote:
>
> This thread is aimed at the specific issue pertaining to the Django 
> Glossary.
>
> But first, after noticing, by accident, a huge spike of views on my G+ 
> profile I think I should explain.  I don't use G+ much because it seems 
> kind-of goofey to me -- that's just me.  If you want to see the real 
> picture, you can look me up on LinkedIn.com under Douglas Epling.
>
> As a web-services/python-programmer-analyst I will never hold a candle to 
> any of the lot of you in this community.  A while back I tried to make a 
> career change by paying my dues in blood, sweat, and tears (not to mention 
> $) by earning a BS in Computer Science as a middle-aged geek wannabe.  This 
> personal initiative was thwarted by the 'tsunami', as Christine Lagarde 
> called it, of 2008.
>
> I am proud that during those academics and unitl this day, I am a Linux 
> afficianado.  I use a Fedora desktop daily, exclusively.  Richard Stallman 
> is my hero.  And just as I was uncerimoniously being kicked out the door of 
> this enterprise where I'd been testing security features on embedded 
> software of network printers, I discovered Python.
>
> Although not a software developer, I know quality in technology when I see 
> it.  Hint:  Microsoft ain't it.  The millenium edition was my first clue!  
> So, I am drawn to the Django community for the promise of caskets filled 
> with gold coins, rubies, and emeralds ... just kidding; I'm a kidder.
>
> So, the glossary!  Yep, it's still there.  I could swear I saw an 
> invitation in the form of a hyper-link to work on the glossary, although I 
> can't seem to locate that in the documentation at this point.  In fact, it 
> almost appears the glossary is being slowly shunted into obscurity.
>
> Here's the thing:  I have taken the liberty of parsing the text documents 
> comprising the Django documentation. 
>   
> I have identified a lengthy list of candidate terminology for possible 
> inclusion in the glossary.  But problems like this simply can not be solved 
> with the same methods used to develop code.  Can you imagine 600 pull 
> requests to add or modify single terms and their meanings?
>
> If this is too hard, I'm hep!  But what if we established a moin, open to 
> anyone who wants to register, where the glossary can be developed?  And 
> establish some kind of temporal cycle with pull requests for glossary 
> updates.
>
> Yours truly,
>
> PS
>
> A Django v2.0 goal for revised and enhanced documentation was unrealistic, 
> and is hereby revoked.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ced6a83f-6b2b-4357-bafc-e5b65c72e497%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Daniele Procida]

On Wed, Jan 6, 2016, Daniele Procida  wrote:

>By all means it's useful to get votes on something like this, even
>before we consider those questions, because if enough people want
>something it's always possible - but be aware that simply getting lots
>of votes for it would only ever be the first and easiest step.

While we're in the realm of the completely hypothetical, if I were going to 
find myself enthusiastic about moving to a new development tracking platform, 
it would be Taiga. 

It's written in Django, by a company that actively supports the Django 
community. It's open-source.  The people who develop it are approachable and 
friendly. It has a nice name.

Daniele

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20160106161756.637596561%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Chris Foresman]

For whatever it's worth, our company switched from Pivotal Tracker to JIRA 
because we added a QA team and they wanted all this flexibility in devising 
bug ticket "workflows." All it did from my perspective is add 47 layers of 
complexity on top of a massively confusing UI and insists on NOT supporting 
markdown while using its own 
sorta-similar-but-different-enough-to-be-constantly-annoying "wiki markup", 
but it can only be supported in certain fields, only I forget which ones it 
works in and which ones it doesn't until I've carefully entered all these 
useful code snippets and links and screenshots and save the ticket and see 
it's just full of gobbledygook.

TL;DR: HATE IT

On Wednesday, January 6, 2016 at 8:34:25 AM UTC-6, Aymeric Augustin wrote:
>
> FWIW Jira seems to be an exception among bug trackers: some people really 
> love it, others really hate it. It depends on who set it up and maintained 
> it in the company where they used it.
>
> Since we don’t have a resident Jira expert, we run the risk that most of 
> the Django community will fall into the “hate it” bucket. To me this is one 
> of the riskier choices we could make.
>
> Anyway it’s unclear to me that the potential benefits of switching to any 
> bug tracker could offset the transition costs, as long as Trac is 
> serviceable.
>
> We’ll see what happens in 2020 if it doesn’t support Python 3 by then (
> http://trac.edgewall.org/ticket/10083, 
> http://trac.edgewall.org/ticket/12130).
>
> -- 
> Aymeric.
>
> On 6 janv. 2016, at 15:19, Michael Manfre  
> wrote:
>
> Agreed with the above for the same reasons.
>
> On Wed, Jan 6, 2016 at 9:17 AM, Shai Berger  > wrote:
>
>> What Marc and James said, and in particular what Daniele said : I get to 
>> use Jira on a daily basis and find it cumbersome and confusing. 
>>
>> Shai see
>>
>>
>> On 6 בינואר 2016 15:43:02 GMT+02:00, Marc Tamlyn > > wrote:
>>>
>>> Yeah, this is a non-starter for me. All bug trackers are bad, we should 
>>> stick with the bad one we are used to.
>>>
>>> Marc
>>>
>>> On 6 January 2016 at 13:26, Victor Sosa >> > wrote:
>>>
 To answer you question:
 There is a plug-in to migrate all the data to Jira and similar to 
 integrate with any it with any in you infrastructure. (I just don't know 
 it 
 all you infrastructure)


 https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html

 On Wednesday, January 6, 2016 at 9:15:41 AM UTC-4, Daniele Procida 
 wrote:
>
> On Wed, Jan 6, 2016, Victor Sosa  wrote: 
>
> >I felt like lost using trac; it is kind of messy. I just don't feel 
> >comfortable 
> >with it. 
> >I see so many open source project using Jira that is just natural. 
> Search 
> >is easy, categorize is easy, look through the all issues and task is 
> quick. 
> > 
> >I would like to propose a vote on Jira as the bugtracker for this 
> project. 
> >Just vote + or - to see how many people agree on this. 
>
> Hi Victor. It's a reasonable proposition, but it's not simply a case 
> of choosing what would be nicer: we also have to make it work in our 
> infrastructure - and that's a huge effort. 
>
> How, for example, would we migrate the many thousands of tickets from 
> Trac to JIRA? 
>
> How would JIRA be integrated into our current deployment 
> infrastructure? 
>
> By all means it's useful to get votes on something like this, even 
> before we consider those questions, because if enough people want 
> something 
> it's always possible - but be aware that simply getting lots of votes for 
> it would only ever be the first and easiest step. 
>
> Having said that: I prefer Trac to JIRA. It's simpler, and faster. 
>
> Daniele 
>
>
 -- 
 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-develop...@googlegroups.com .
 To post to this group, send email to django-d...@googlegroups.com 
 .
 Visit this group at https://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%40googlegroups.com
  
 
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to 

Re: Vote on Jira as bugtracker

[Nick Sarbicki]

>
> FWIW Jira seems to be an exception among bug trackers: some people really
> love it, others really hate it. It depends on who set it up and maintained
> it in the company where they used it.
>
> Since we don’t have a resident Jira expert, we run the risk that most of
> the Django community will fall into the “hate it” bucket. To me this is one
> of the riskier choices we could make.
>
> Anyway it’s unclear to me that the potential benefits of switching to any
> bug tracker could offset the transition costs, as long as Trac is
> serviceable.
>
> We’ll see what happens in 2020 if it doesn’t support Python 3 by then (
> http://trac.edgewall.org/ticket/10083,
> http://trac.edgewall.org/ticket/12130).
>

Could always look at Bloodhound (http://bloodhound.apache.org/) if after
something similar. Not that it supports Py3 yet.

But I'm with everyone else. It's not worth it.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGuvt93%2BabKpnA%2BFC2Ny5HYn3p_8mdS_%2BrPV3jg3NFoV%3DgHvyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending JSONField serialization

[Michael Manfre]

On Wed, Jan 6, 2016 at 9:58 AM, Tom Christie  wrote:

> Customizing the encoder (or even using DjangoJSONEncoder by default) isn't
> so bad.
>
> I'm less convinced about the usefulness of customizing the decoder - once
> you've encoded the data into JSON any additional type information is lost,
> so casting back to python primitives is always going to need to be handled
> explicitly.
>

Whether or not a configurable decoder seems useful for the situations we
can think of, only allowing users to configure half of the encode/decode
cycle seems odd to me. Allowing both to be configurable requires a trivial
amount of extra effort to implement and maintain.

Regards,
Michael Manfre

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBvV_AAS_rcZkHTC38_mJACL4uj3w2jRBckPCp0XLZ4YsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Review Request] Added support for database delegated fields (like AutoField)

[Owais Lone]

Hi, I would really appreciate if someone could review the API design (and 
implementation) for a PR I created. The PR implements support for fields that 
are assigned a value by the database (using a default value or trigger) instead 
of Django. It also adds support for PostgreSQL’s RETURNING and Oracle’s 
RETURNING INTO clauses.

This will allow us to have AutoField like behaviour on fields other than the 
primary key or have primary key fields other than Integer and BigInteger types. 

The PR also sets the stage for returning primary keys (and optionally other 
fields) from the bulk_create operation on PostgreSQL and Oracle.

Pull request: https://github.com/django/django/pull/5904
Django ticket: https://code.djangoproject.com/ticket/21454

Thanks

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CE5C6CD8-146E-4680-89A7-1351DF0CA76F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending JSONField serialization

[Tom Christie]

Customizing the encoder (or even using DjangoJSONEncoder by default) isn't 
so bad.

I'm less convinced about the usefulness of customizing the decoder - once 
you've encoded the data into JSON any additional type information is lost, 
so casting back to python primitives is always going to need to be handled 
explicitly.

Being able to set field values that contain eg datetimes *could* be a 
useful shortcut, but it only makes sense to me if we make it clear that 
values passed into the JSON field will only ever be stored/retrieved as 
their JSON primitive representations.

Cheers,

  Tom

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3fe79e25-bbab-484a-abd5-051e60fcc189%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Aymeric Augustin]

FWIW Jira seems to be an exception among bug trackers: some people really love 
it, others really hate it. It depends on who set it up and maintained it in the 
company where they used it.

Since we don’t have a resident Jira expert, we run the risk that most of the 
Django community will fall into the “hate it” bucket. To me this is one of the 
riskier choices we could make.

Anyway it’s unclear to me that the potential benefits of switching to any bug 
tracker could offset the transition costs, as long as Trac is serviceable.

We’ll see what happens in 2020 if it doesn’t support Python 3 by then 
(http://trac.edgewall.org/ticket/10083, http://trac.edgewall.org/ticket/12130).

-- 
Aymeric.

> On 6 janv. 2016, at 15:19, Michael Manfre  wrote:
> 
> Agreed with the above for the same reasons.
> 
> On Wed, Jan 6, 2016 at 9:17 AM, Shai Berger  > wrote:
> What Marc and James said, and in particular what Daniele said : I get to use 
> Jira on a daily basis and find it cumbersome and confusing. 
> 
> Shai see
> 
> 
> On 6 בינואר 2016 15:43:02 GMT+02:00, Marc Tamlyn  > wrote:
> Yeah, this is a non-starter for me. All bug trackers are bad, we should stick 
> with the bad one we are used to.
> 
> Marc
> 
> On 6 January 2016 at 13:26, Victor Sosa  > wrote:
> To answer you question:
> There is a plug-in to migrate all the data to Jira and similar to integrate 
> with any it with any in you infrastructure. (I just don't know it all you 
> infrastructure)
> 
> https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html 
> 
> 
> On Wednesday, January 6, 2016 at 9:15:41 AM UTC-4, Daniele Procida wrote:
> On Wed, Jan 6, 2016, Victor Sosa > wrote: 
> 
> >I felt like lost using trac; it is kind of messy. I just don't feel 
> >comfortable 
> >with it. 
> >I see so many open source project using Jira that is just natural. Search 
> >is easy, categorize is easy, look through the all issues and task is quick. 
> > 
> >I would like to propose a vote on Jira as the bugtracker for this project. 
> >Just vote + or - to see how many people agree on this. 
> 
> Hi Victor. It's a reasonable proposition, but it's not simply a case of 
> choosing what would be nicer: we also have to make it work in our 
> infrastructure - and that's a huge effort. 
> 
> How, for example, would we migrate the many thousands of tickets from Trac to 
> JIRA? 
> 
> How would JIRA be integrated into our current deployment infrastructure? 
> 
> By all means it's useful to get votes on something like this, even before we 
> consider those questions, because if enough people want something it's always 
> possible - but be aware that simply getting lots of votes for it would only 
> ever be the first and easiest step. 
> 
> Having said that: I prefer Trac to JIRA. It's simpler, and faster. 
> 
> Daniele 
> 
> 
> -- 
> 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 post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%40googlegroups.com
>  
> .
> 
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 
> -- 
> 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 post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CDE1F163-5500-446F-B8A4-FE512F944C57%40platonix.com
>  
> 

Re: Extending JSONField serialization

[Aymeric Augustin]

Hello Dwight,

I was trying to express the fact that JSONField is appropriate for storing data 
that won’t be used for joining other tables, filtering, aggregating, etc. but 
rather just for reading.

“Not mission-critical” was a simplification. That said, data that meets the 
criteria above tends not to be the most important data in an application.

In your example, at worst, if your app fails to read what it wrote previously 
to the JSON field, the user will just have to set their preferences again.

-- 
Aymeric.

> On 6 janv. 2016, at 12:33, Dwight Gunning  wrote:
> 
> It's interesting that you say JSON Fields shouldn't be used for mission 
> critical data. Is that widely recognised?
> 
> I feel like there are genuine uses cases for using JSON Fields to store 
> mission critical data. For instance, a Javascript single-page-app style 
> client with a set of user preferences to adjust the UI look and feel. These 
> preferences need to be persisted between sessions but don't really need to be 
> normalised or separated into individual fields by Django, aside from perhaps 
> light validation.
> 
> Datetime encoding/decoding to integrate with third party systems is a regular 
> headache for me. I typically writ DRF serializers to take care of datetime 
> formatting, but a more general solution closer to the data layer would be 
> nice.
> 
> Regards,
> 
> Dwight
> --
> 
> On Tuesday, January 5, 2016 at 6:49:16 PM UTC+1, Aymeric Augustin wrote:
> > On 5 janv. 2016, at 18:37, Tom Christie gmail.com 
> > > wrote: 
> > 
> >> Should JSONField accept additional kwargs to customize the encoder and the 
> >> decoder? 
> > 
> > Quick take here: 
> > 
> > That sounds like a bit too much "cleverness" to me. The most obvious issue 
> > it'd cause is putting values of one type into the field, but getting 
> > objects of a different type back. (eg datetime getting coerced into a 
> > string on the way in, and left as a string on the way out). 
> 
> Yes, I understand how that could surprise a developer. 
> 
> A smart deserializer that would attempt to convert some strings back to their 
> original type, based on their content, would create the opposite risk: a 
> string that matches the format of a date could be accidentally returned as a 
> date. 
> 
> I wouldn’t do this for mission-critical data — but then I wouldn’t store it 
> in a JSON field either. Django projects should only use a JSON field for data 
> that isn’t worth normalizing into actual fields. Writing a schema to map keys 
> to types defeats the point; if you’re writing a schema, just express it with 
> traditional model fields. 
> 
> I don’t think Django should (de)serialize non-native JSON types by default, 
> but it should make it possible through public APIs, as this is a common 
> requirement. For my use case, logging, the convenience of being able to store 
> dates, datetimes and decimals without resorting the heavy guns (DRF 
> serializers) helps a lot. 
> 
> -- 
> Aymeric. 
> 
> 
> -- 
> 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 post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/a2868ea8-c559-4240-aaba-dbf1f6efbe64%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  (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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/E507FE42-D738-410B-B447-D152A67797A3%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Michael Manfre]

Agreed with the above for the same reasons.

On Wed, Jan 6, 2016 at 9:17 AM, Shai Berger  wrote:

> What Marc and James said, and in particular what Daniele said : I get to
> use Jira on a daily basis and find it cumbersome and confusing.
>
> Shai see
>
>
> On 6 בינואר 2016 15:43:02 GMT+02:00, Marc Tamlyn 
> wrote:
>>
>> Yeah, this is a non-starter for me. All bug trackers are bad, we should
>> stick with the bad one we are used to.
>>
>> Marc
>>
>> On 6 January 2016 at 13:26, Victor Sosa  wrote:
>>
>>> To answer you question:
>>> There is a plug-in to migrate all the data to Jira and similar to
>>> integrate with any it with any in you infrastructure. (I just don't know it
>>> all you infrastructure)
>>>
>>>
>>> https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html
>>>
>>> On Wednesday, January 6, 2016 at 9:15:41 AM UTC-4, Daniele Procida wrote:

 On Wed, Jan 6, 2016, Victor Sosa  wrote:

 >I felt like lost using trac; it is kind of messy. I just don't feel
 >comfortable
 >with it.
 >I see so many open source project using Jira that is just natural.
 Search
 >is easy, categorize is easy, look through the all issues and task is
 quick.
 >
 >I would like to propose a vote on Jira as the bugtracker for this
 project.
 >Just vote + or - to see how many people agree on this.

 Hi Victor. It's a reasonable proposition, but it's not simply a case of
 choosing what would be nicer: we also have to make it work in our
 infrastructure - and that's a huge effort.

 How, for example, would we migrate the many thousands of tickets from
 Trac to JIRA?

 How would JIRA be integrated into our current deployment
 infrastructure?

 By all means it's useful to get votes on something like this, even
 before we consider those questions, because if enough people want something
 it's always possible - but be aware that simply getting lots of votes for
 it would only ever be the first and easiest step.

 Having said that: I prefer Trac to JIRA. It's simpler, and faster.

 Daniele

 --
>>> 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 post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CDE1F163-5500-446F-B8A4-FE512F944C57%40platonix.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBtQmB45ogstE2PFE%3DDxw9EVgdjaOyw5UeXKHgLD74dQHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Shai Berger]

What Marc and James said, and in particular what Daniele said : I get to use 
Jira on a daily basis and find it cumbersome and confusing. 

Shai see

On 6 בינואר 2016 15:43:02 GMT+02:00, Marc Tamlyn  wrote:
>Yeah, this is a non-starter for me. All bug trackers are bad, we should
>stick with the bad one we are used to.
>
>Marc
>
>On 6 January 2016 at 13:26, Victor Sosa  wrote:
>
>> To answer you question:
>> There is a plug-in to migrate all the data to Jira and similar to
>> integrate with any it with any in you infrastructure. (I just don't
>know it
>> all you infrastructure)
>>
>>
>>
>https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html
>>
>> On Wednesday, January 6, 2016 at 9:15:41 AM UTC-4, Daniele Procida
>wrote:
>>>
>>> On Wed, Jan 6, 2016, Victor Sosa  wrote:
>>>
>>> >I felt like lost using trac; it is kind of messy. I just don't feel
>>> >comfortable
>>> >with it.
>>> >I see so many open source project using Jira that is just natural.
>>> Search
>>> >is easy, categorize is easy, look through the all issues and task
>is
>>> quick.
>>> >
>>> >I would like to propose a vote on Jira as the bugtracker for this
>>> project.
>>> >Just vote + or - to see how many people agree on this.
>>>
>>> Hi Victor. It's a reasonable proposition, but it's not simply a case
>of
>>> choosing what would be nicer: we also have to make it work in our
>>> infrastructure - and that's a huge effort.
>>>
>>> How, for example, would we migrate the many thousands of tickets
>from
>>> Trac to JIRA?
>>>
>>> How would JIRA be integrated into our current deployment
>infrastructure?
>>>
>>> By all means it's useful to get votes on something like this, even
>before
>>> we consider those questions, because if enough people want something
>it's
>>> always possible - but be aware that simply getting lots of votes for
>it
>>> would only ever be the first and easiest step.
>>>
>>> Having said that: I prefer Trac to JIRA. It's simpler, and faster.
>>>
>>> Daniele
>>>
>>> --
>> 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 post to this group, send email to
>django-developers@googlegroups.com.
>> Visit this group at
>https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>>
>https://groups.google.com/d/msgid/django-developers/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%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  (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 post to this group, send email to
>django-developers@googlegroups.com.
>Visit this group at https://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/CAMwjO1GrgWYXB7nZrVNmRqXQ7JcqTUaWQuMPmEJELBz2W5gjeQ%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CDE1F163-5500-446F-B8A4-FE512F944C57%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Florian Apolloner]

Ditto.

On Wednesday, January 6, 2016 at 2:43:44 PM UTC+1, Marc Tamlyn wrote:
>
> Yeah, this is a non-starter for me. All bug trackers are bad, we should 
> stick with the bad one we are used to.
>
> Marc
>
> On 6 January 2016 at 13:26, Victor Sosa  
> wrote:
>
>> To answer you question:
>> There is a plug-in to migrate all the data to Jira and similar to 
>> integrate with any it with any in you infrastructure. (I just don't know it 
>> all you infrastructure)
>>
>>
>> https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html
>>
>> On Wednesday, January 6, 2016 at 9:15:41 AM UTC-4, Daniele Procida wrote:
>>>
>>> On Wed, Jan 6, 2016, Victor Sosa  wrote: 
>>>
>>> >I felt like lost using trac; it is kind of messy. I just don't feel 
>>> >comfortable 
>>> >with it. 
>>> >I see so many open source project using Jira that is just natural. 
>>> Search 
>>> >is easy, categorize is easy, look through the all issues and task is 
>>> quick. 
>>> > 
>>> >I would like to propose a vote on Jira as the bugtracker for this 
>>> project. 
>>> >Just vote + or - to see how many people agree on this. 
>>>
>>> Hi Victor. It's a reasonable proposition, but it's not simply a case of 
>>> choosing what would be nicer: we also have to make it work in our 
>>> infrastructure - and that's a huge effort. 
>>>
>>> How, for example, would we migrate the many thousands of tickets from 
>>> Trac to JIRA? 
>>>
>>> How would JIRA be integrated into our current deployment infrastructure? 
>>>
>>> By all means it's useful to get votes on something like this, even 
>>> before we consider those questions, because if enough people want something 
>>> it's always possible - but be aware that simply getting lots of votes for 
>>> it would only ever be the first and easiest step. 
>>>
>>> Having said that: I prefer Trac to JIRA. It's simpler, and faster. 
>>>
>>> Daniele 
>>>
>>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%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  (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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1628cb76-dc55-483e-a44f-b65a67f46442%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Marc Tamlyn]

Yeah, this is a non-starter for me. All bug trackers are bad, we should
stick with the bad one we are used to.

Marc

On 6 January 2016 at 13:26, Victor Sosa  wrote:

> To answer you question:
> There is a plug-in to migrate all the data to Jira and similar to
> integrate with any it with any in you infrastructure. (I just don't know it
> all you infrastructure)
>
>
> https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html
>
> On Wednesday, January 6, 2016 at 9:15:41 AM UTC-4, Daniele Procida wrote:
>>
>> On Wed, Jan 6, 2016, Victor Sosa  wrote:
>>
>> >I felt like lost using trac; it is kind of messy. I just don't feel
>> >comfortable
>> >with it.
>> >I see so many open source project using Jira that is just natural.
>> Search
>> >is easy, categorize is easy, look through the all issues and task is
>> quick.
>> >
>> >I would like to propose a vote on Jira as the bugtracker for this
>> project.
>> >Just vote + or - to see how many people agree on this.
>>
>> Hi Victor. It's a reasonable proposition, but it's not simply a case of
>> choosing what would be nicer: we also have to make it work in our
>> infrastructure - and that's a huge effort.
>>
>> How, for example, would we migrate the many thousands of tickets from
>> Trac to JIRA?
>>
>> How would JIRA be integrated into our current deployment infrastructure?
>>
>> By all means it's useful to get votes on something like this, even before
>> we consider those questions, because if enough people want something it's
>> always possible - but be aware that simply getting lots of votes for it
>> would only ever be the first and easiest step.
>>
>> Having said that: I prefer Trac to JIRA. It's simpler, and faster.
>>
>> Daniele
>>
>> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%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  (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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GrgWYXB7nZrVNmRqXQ7JcqTUaWQuMPmEJELBz2W5gjeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Victor Sosa]

To answer you question:
There is a plug-in to migrate all the data to Jira and similar to integrate 
with any it with any in you infrastructure. (I just don't know it all you 
infrastructure)

https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html

On Wednesday, January 6, 2016 at 9:15:41 AM UTC-4, Daniele Procida wrote:
>
> On Wed, Jan 6, 2016, Victor Sosa  
> wrote: 
>
> >I felt like lost using trac; it is kind of messy. I just don't feel 
> >comfortable 
> >with it. 
> >I see so many open source project using Jira that is just natural. Search 
> >is easy, categorize is easy, look through the all issues and task is 
> quick. 
> > 
> >I would like to propose a vote on Jira as the bugtracker for this 
> project. 
> >Just vote + or - to see how many people agree on this. 
>
> Hi Victor. It's a reasonable proposition, but it's not simply a case of 
> choosing what would be nicer: we also have to make it work in our 
> infrastructure - and that's a huge effort. 
>
> How, for example, would we migrate the many thousands of tickets from Trac 
> to JIRA? 
>
> How would JIRA be integrated into our current deployment infrastructure? 
>
> By all means it's useful to get votes on something like this, even before 
> we consider those questions, because if enough people want something it's 
> always possible - but be aware that simply getting lots of votes for it 
> would only ever be the first and easiest step. 
>
> Having said that: I prefer Trac to JIRA. It's simpler, and faster. 
>
> Daniele 
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[James Bennett]

I'd be against such a change. I've used a lot of bug trackers, and the only
thing I've learned is there is no good one; replacing one with another just
swaps one set of annoying limitations/frustrations for another. And since
there's a lot of inertia in whatever's currently being used, and it would
require a lot of work and effort to switch to something else, I don't see
enough gain from doing so to support a switch, especially since we at least
have a ton of experience working around Trac's limitations now, and would
have to re-learn all of that to switch to something else.

On Wed, Jan 6, 2016 at 5:55 AM, Victor Sosa  wrote:

> HI,
>
> I felt like lost using trac; it is kind of messy. I just don't feel 
> comfortable
> with it.
> I see so many open source project using Jira that is just natural. Search
> is easy, categorize is easy, look through the all issues and task is quick.
>
> I would like to propose a vote on Jira as the bugtracker for this project.
> Just vote + or - to see how many people agree on this.
>
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b80ec53d-ec62-4b77-a8cf-72ca1e852c78%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  (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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_3Fje%3D21CnTgQ0mtWzG-F-Bs%3D0B_WLvf4wVg%2Bo-%3Dixkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Daniele Procida]

On Wed, Jan 6, 2016, Victor Sosa  wrote:

>I felt like lost using trac; it is kind of messy. I just don't feel
>comfortable 
>with it. 
>I see so many open source project using Jira that is just natural. Search 
>is easy, categorize is easy, look through the all issues and task is quick. 
>
>I would like to propose a vote on Jira as the bugtracker for this project. 
>Just vote + or - to see how many people agree on this.

Hi Victor. It's a reasonable proposition, but it's not simply a case of 
choosing what would be nicer: we also have to make it work in our 
infrastructure - and that's a huge effort.

How, for example, would we migrate the many thousands of tickets from Trac to 
JIRA?

How would JIRA be integrated into our current deployment infrastructure?

By all means it's useful to get votes on something like this, even before we 
consider those questions, because if enough people want something it's always 
possible - but be aware that simply getting lots of votes for it would only 
ever be the first and easiest step.

Having said that: I prefer Trac to JIRA. It's simpler, and faster. 

Daniele

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20160106131522.1112436433%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Vote on Jira as bugtracker

[Victor Sosa]

HI,

I felt like lost using trac; it is kind of messy. I just don't feel comfortable 
with it. 
I see so many open source project using Jira that is just natural. Search 
is easy, categorize is easy, look through the all issues and task is quick. 

I would like to propose a vote on Jira as the bugtracker for this project. 
Just vote + or - to see how many people agree on this.


-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b80ec53d-ec62-4b77-a8cf-72ca1e852c78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending JSONField serialization

[Dwight Gunning]

It's interesting that you say JSON Fields shouldn't be used for mission 
critical data. Is that widely recognised?

I feel like there are genuine uses cases for using JSON Fields to store 
mission critical data. For instance, a Javascript single-page-app style 
client with a set of user preferences to adjust the UI look and feel. These 
preferences need to be persisted between sessions but don't really need to 
be normalised or separated into individual fields by Django, aside from 
perhaps light validation.

Datetime encoding/decoding to integrate with third party systems is a 
regular headache for me. I typically writ DRF serializers to take care of 
datetime formatting, but a more general solution closer to the data layer 
would be nice.

Regards,

Dwight
--

On Tuesday, January 5, 2016 at 6:49:16 PM UTC+1, Aymeric Augustin wrote:
>
> > On 5 janv. 2016, at 18:37, Tom Christie  > wrote: 
> > 
> >> Should JSONField accept additional kwargs to customize the encoder and 
> the decoder? 
> > 
> > Quick take here: 
> > 
> > That sounds like a bit too much "cleverness" to me. The most obvious 
> issue it'd cause is putting values of one type into the field, but getting 
> objects of a different type back. (eg datetime getting coerced into a 
> string on the way in, and left as a string on the way out). 
>
> Yes, I understand how that could surprise a developer. 
>
> A smart deserializer that would attempt to convert some strings back to 
> their original type, based on their content, would create the opposite 
> risk: a string that matches the format of a date could be accidentally 
> returned as a date. 
>
> I wouldn’t do this for mission-critical data — but then I wouldn’t store 
> it in a JSON field either. Django projects should only use a JSON field for 
> data that isn’t worth normalizing into actual fields. Writing a schema to 
> map keys to types defeats the point; if you’re writing a schema, just 
> express it with traditional model fields. 
>
> I don’t think Django should (de)serialize non-native JSON types by 
> default, but it should make it possible through public APIs, as this is a 
> common requirement. For my use case, logging, the convenience of being able 
> to store dates, datetimes and decimals without resorting the heavy guns 
> (DRF serializers) helps a lot. 
>
> -- 
> Aymeric. 
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a2868ea8-c559-4240-aaba-dbf1f6efbe64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.