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 co
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 curr
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
When I create a custom inclusion tag, I commonly use the
`takes_context=True` functionality, which passes in the current context
into the custom tag's function as the first parameter, `context`. I
recently ran into an issue with admittedly how *I* sometimes write these
tags.
Depending on the u
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
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.
``filenam
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
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
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
de
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 sho
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
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 suppo
>
> 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
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,
> s
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 O
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
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
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
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
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
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
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 yo
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, 20
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
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 woul
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 bugt
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
27 matches
Mail list logo