On Sun, Jun 8, 2008 at 3:06 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive
Hi guys,
recently I found out that for much easier admin interface role-based
customization,
some methods that doesn't have access to request and edited object
now, needs them.
However, I don't want to apply threadlocal patch -- why it's not added
to django yet if it is the best way to go?
And I
Hi, all.
On Sat, Jun 7, 2008 at 9:38 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> And for the record, I do think that *post-1.0* we should do more
> frequent releases, because it'll be quite a bit simpler to do at that
> point. I just think that right now it's not really worth the trouble;
>
On Sat, Jun 7, 2008 at 6:17 PM, James Bennett <[EMAIL PROTECTED]> wrote:
...
> Newforms-admin needs to get done. ... If that means organizing a sprint or
> two on it
> and then doing a trunk merge to get more eyeballs on the code, then
> let's do that instead.
As someone who would benefit from
On Sat, Jun 7, 2008 at 7:23 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
...
> Where I work we use 0.96 (though I use trunk on my personal projects).
> We use 0.96 because we have up to 12 separate Django projects
> rotating through at a time
In that environment, perhaps you should work on tools
And for the record, I do think that *post-1.0* we should do more
frequent releases, because it'll be quite a bit simpler to do at that
point. I just think that right now it's not really worth the trouble;
the same people who currently complain that they have to use a
packaged release but want a
> Newforms-admin needs to get done. Putting it off from the first couple
> betas or RCs will just increase the temptation to put it off further,
> so what we should do is identify anything that's slowing it down and
> work to resolve that. If that means organizing a sprint or two on it
> and then
On Jun 7, 5:17 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> Newforms-admin needs to get done. Putting it off from the first couple
> betas or RCs will just increase the temptation to put it off further,
> so what we should do is identify anything that's slowing it down and
> work to resolve
El sáb, 07-06-2008 a las 19:53 -0500, James Bennett escribió:
> On Sat, Jun 7, 2008 at 7:46 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> > Right now Backwards Incompatible changes are documented in a wiki page,
> > with some disadvantages:
>
> And in the release notes when a new release happens.
El sáb, 07-06-2008 a las 17:54 -0700, [EMAIL PROTECTED] escribió:
> I'd be +1 on this, the only downside is that whoever commits the patch
> will need to insert the correct revision at commit time.
You can't do so unless you do svn info, svn commit both very fast. That
would go on a new section
I'd be +1 on this, the only downside is that whoever commits the patch
will need to insert the correct revision at commit time.
PS: http://www.pointy-stick.com/blog/2008/05/21/not-here-right-now/
On Jun 7, 7:46 pm, Marc Fargas <[EMAIL PROTECTED]> wrote:
> Hi there,
> Right now Backwards
On Sat, Jun 7, 2008 at 7:46 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> Right now Backwards Incompatible changes are documented in a wiki page,
> with some disadvantages:
And in the release notes when a new release happens.
--
"Bureaucrat Conrad, you are technically correct -- the best kind
Hi there,
Right now Backwards Incompatible changes are documented in a wiki page,
with some disadvantages:
* There's a reference in documentation to the wiki (install.txt:182)
* When commiting those changes the wiki has to be updated by hand.
* Some people expect either a
On Sat, Jun 7, 2008 at 4:45 PM, Tim Chase
<[EMAIL PROTECTED]> wrote:
> I'm not sure blessing it with a number does much but pander to
> folks that are scared to make a tough call:
>
> Use 0.96: blessed with a magic number, but old and not much like
> 1.0 will be
>
> or use Trunk: suggested (but
>> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
>> rc or two, and then a final release. Features that are done by the
>> dates get released, those that aren't, don't. Make these dates
>> aggressive but not crazy. And -- here's the controversial part -- make
>>
On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive
On Sat, Jun 7, 2008 at 11:48 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> I think the most often reason why I've heard is that it takes time to
> create a release, post it, push security patches to it, etc. Which
> makes sense, but at the same time there are a lot of valid points in
> the blog
I think one of the best points this article raises is that as long as
a large number of people are using trunk this forces us to be way more
careful about backwards compatibility, and I think that often times
gets in the way of getting things done. One suggestion that I have
heard is that every
On Jun 7, 2008, at 1:06 PM, Jacob Kaplan-Moss wrote:
>
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And --
On Sat, Jun 7, 2008 at 1:03 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> One suggestion is to assign to "foo.bar_id" instead of "foo.bar"; that
> skips the validation hook. But if you've got more suggestions I'm
> listening...
I got around it just by putting the FK assignments in a try
(... apologies if this message doesn't end up in the right thread, I had
to cut'n'paste everything to get the original message in here -
hopefully with the correct headers)
Jacob Kaplan-Moss wrote:
> For the record, and if the author of this blog post is reading: I
> can't stand the
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And -- here's the controversial part -- make
> newforms-admin
On Sat, Jun 7, 2008 at 12:35 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> I was just bitten by this (having since svn up'd trunk). I have some
> data migration scripts that make a lot of assignments up front, extra
> logic to clean up a few things, and then wraps the save() in a try
> block.
On Sun, Jun 1, 2008 at 8:11 AM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
> Why not defer it to save()? Currently you can assign invalid values to
> other fields and it won't break until save():
>
> obj.time = 125 # Ok
> obj.save() # ProgrammingError
>
> And many things even won't break at all
On Sat, Jun 7, 2008 at 12:06 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive
For the record, and if the author of this blog post is reading: I
can't stand the passive-aggressiveness of making a rant on your blog
and waiting for us to read it. I wish this had been brought up here
instead of trying to drum of some supposed "outcry" for a new release.
That said, he's got a
I'm pretty sure its been stated several times on the board but there will be
no versions released between .96 and 1.0.
On Sat, Jun 7, 2008 at 12:48 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> Regarding this blog post:
> http://www.technobabble.dk/2008/jun/07/django-importance-releases/
>
> I
Ok. I already added a ticket for this issue.
http://code.djangoproject.com/ticket/7388
On 6 jun, 15:20, "Justin Lilly" <[EMAIL PROTECTED]> wrote:
> As its a visual issue, I'd also probably include a screenshot.
>
> On Fri, Jun 6, 2008 at 8:48 AM, Russell Keith-Magee <[EMAIL PROTECTED]>
> wrote:
28 matches
Mail list logo
