Django releases

[Rob Hudson]

Regarding this blog post:
http://www.technobabble.dk/2008/jun/07/django-importance-releases/

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 post.

I'm curious if it would help to have a release team, or just certain
people to "own" a release.

For example, I for one could help (given the right privileges) package
up a 0.97 release, tag it, update the various bits on the website, and
sit by ready to make a patch release for any security updates.
Someone else could "own" the 0.98 release. Once 0.97 is no longer
supported, that frees me up to "own" another release.

Just a thought.

-Rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Justin Lilly]

I'm pretty sure its been stated several times on the board but there will be
no versions released between .96 and 1.0.

Post by Rob Hudson
http://www.technobabble.dk/2008/jun/07/django-importance-releases/
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 post.
I'm curious if it would help to have a release team, or just certain
people to "own" a release.
For example, I for one could help (given the right privileges) package
up a 0.97 release, tag it, update the various bits on the website, and
sit by ready to make a patch release for any security updates.
Someone else could "own" the 0.98 release. Once 0.97 is no longer
supported, that frees me up to "own" another release.
Just a thought.
-Rob

--
Justin Lilly
Web Developer/Designer
http://justinlilly.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jacob Kaplan-Moss]

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 valid point. We've been delaying a release
waiting on newforms-admin for quite some time, but unfortunatly we
don't have a lot of folks working on that branch. Brian, Karan, and
Joseph are certainly doing what they can, but there's quite a bit of
work to be done there.

As I see it, we've got three options:

* Wait for newforms-admin to be done, merge it, and release 1.0 (well,
a series of beta/rcs, then final). This has been "plan A" all along.

* Release an interim release right away to respond to this supposed
"outcry" for a release. I've been opposed to this all along because I
don't the quality of something released just to get folks to shut up
will be all that high. A snapshot with an "official" number will
likely do more harm than good.

Which brings me to a middle ground I'd like to propose. I've been
meaning to propose this for a few weeks, but haven't gotten around to
writing it up fully; here's the half-assed proposal which I can follow
with more details if there are questions:

* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

Thoughts?

Jacob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Rob Hudson]

On Sat, Jun 7, 2008 at 12:06 PM, Jacob Kaplan-Moss

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

This is similar to the Ubuntu release schedule -- release every 6
months and whatever is done/stable at the time makes it, otherwise
things wait for the next release (which isn't too far out).

+1 from me, and it provides for a little motivation since there is a
target date on the horizon.

-Rob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[f***@public.gmane.org]

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.
Thoughts?

-0

I disagree about the newforms-admin part being optional. Right now
the admin is great, but it's tightly coupled with the models. With
newforms-admin, there's not only a great increase in the power of the
admin app itself, but it's also a demonstration of best practices for
creating generic apps with Django. Also, if a 1.0 got released with
oldforms-admin, there will be the inevitable media fanfare, so imagine
the books, tutorials, articles, etc. that will be written which
referencing the old ways.

-Eric Florenzano
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Tim Chase]

Post by f***@public.gmane.org

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.
Thoughts?

-1

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 not blessed with a number), much
closer to like 1.0 will be, and still some changes to be expected
when new-forms hits.

Blessing an interim release means supporting it...namely without
the features that have been planned for 1.0 and adds confusion as
to what comprises "Django 1.0"

If Django 1.0 should have NFA and QSR, anything short of that
should not be called 1.0, IMHO.

Post by f***@public.gmane.org
-0
I disagree about the newforms-admin part being optional. Right now
the admin is great, but it's tightly coupled with the models. With
newforms-admin, there's not only a great increase in the power of the
admin app itself, but it's also a demonstration of best practices for
creating generic apps with Django. Also, if a 1.0 got released with
oldforms-admin, there will be the inevitable media fanfare, so imagine
the books, tutorials, articles, etc. that will be written which
referencing the old ways.

I add my support to Eric's reasoning.

-tim





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Rob Hudson]

On Sat, Jun 7, 2008 at 4:45 PM, Tim Chase

Post by Tim Chase
I'm not sure blessing it with a number does much but pander to
Use 0.96: blessed with a magic number, but old and not much like
1.0 will be
or use Trunk: suggested (but not blessed with a number), much
closer to like 1.0 will be, and still some changes to be expected
when new-forms hits.

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 and all at various phases of development.
We don't have the resources to continuously update all of them to
trunk and fix the various backward incompatible changes that might
crop up, and each one can't be on its own trunk release or trying to
assemble any sort of library would be a nightmare. Not even
mentioning having to support various Django releases on our production
servers. So we're stuck on 0.96 until 1.0 comes along.

Not so much a tough call to pick 0.96 in our case, but I'm jealous at
the more than 1 year of great features in Django trunk.

-Rob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jeremy Dunck]

On Sat, Jun 7, 2008 at 7:23 PM, Rob Hudson <treborhudson-***@public.gmane.org> wrote:
...

Post by Rob Hudson
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 techniques
to make automated porting work. Otherwise, you're going to have a
painful legacy problem.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Rob Hudson]

Post by Jeremy Dunck

Post by Rob Hudson
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 techniques
to make automated porting work. Otherwise, you're going to have a
painful legacy problem.

I think it depends on the project, but I wouldn't mind hearing more of
your thoughts on this because it's something I have to deal with.
Perhaps we should take it offline unless others might benefit from the
conversation.

When our projects are done, they're done. They work as intended and I
don't see any reason to upgrade them from 0.96 to 1.0. If it ain't
broke, why fix it? When 1.0 comes out, we'll upgrade our core
libraries to work against 1.0 and that will be our new default. The
only reasons I can think of to want to upgrade a finished site is for
security or major performance enhancements -- one of which is usually
back-ported to 0.96 for as long as it's supported (which I'm not sure
Django has specified). What I'm wishing for in trunk are more
developer friendly features -- things that make it easier on the
developers.

Please tell me more about the legacy problem you are predicting.

And for Django devs -- are there specific dates or number of releases
when Django no longer rolls out security patches for older releases?

Thanks,
Rob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jeremy Dunck]

On Mon, Jun 9, 2008 at 11:37 AM, Rob Hudson <treborhudson-***@public.gmane.org> wrote:
...

Post by Rob Hudson
When our projects are done, they're done.

Ah, that's a foreign concept to me. In that case, yeah, your strategy
sounds good. :)

...

Post by Rob Hudson
Please tell me more about the legacy problem you are predicting.

Our projects are never done; the codebase is living. We have a
rolling migration problem, and our codebase is ever expanding. We try
to keep at a recent (but not tip) rev at all times.

Post by Rob Hudson
And for Django devs -- are there specific dates or number of releases
when Django no longer rolls out security patches for older releases?

I believe it's one official release back. James will know better.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

Post by Jeremy Dunck
I believe it's one official release back. James will know better.

For security we patch trunk, of course, as well as current stable
release plus the two previous releases. This means we currently
provide security updates for trunk, 0.96, 0.95 and 0.91.

As an aside, we have a number of clients running on checkouts of the
SVN "bugfixes" branches for their versions of Django, which makes
management of that sort of thing quite easy -- security updates are
just an 'svn up' away for them, and for stuff we host it actually
reduces down to a single Capistrano task to deploy that :)

[Rob Hudson]

Posting this here rather than someone's blog post comments:

Just a note up front, Django has completely changed the way I build
websites and I'm totally enamored with it, but I'm trying to think of
how official releases could have benefitted myself in my situation and
this is what I came up with...

Let's pretend the following history occurred...

* 0.97 was released with the major change being the update to unicode.
* 0.98 was released whose main features were auto escaping and QSRF.
* 0.99 will soon be released whose main feature is newforms admin.
* 1.0 will be released with minor updates and stabilization.

Some benefits I see if this had happened. Specific pretend version
examples reference those above...

* Easier to know up front what's new, backwards incompatible, etc.
because there'd be release notes and we can plan to migrate when
ready. Versus an arbitrary revision and checking the backwards
incompat wiki page, looking at docs to see what has "New in
Development Version", etc.

* Easier to set up a server to host Django apps depending on all of
0.96, 0.97, 0.98 vs possibly having revs -- at least you can simply
svn up a point release branch for security fixes. On revs you'd have
to back port a patch to a certain rev if a security fix was released
to not also update the stuff you don't want. Another example is
Webfaction -- they now offer 0.96 and "trunk", but who's trunk is it
and when is it updated? I don't want my website to break b/c they
updated out from underneath me. I'd much rather have a recent point
release that I can depend on and still get some of the new goodies in
recent Django.

* Online HTML documentation is frozen with each release. If we were
tracking individual revs, this is not true -- docs would only be
frozen with the Django tree. This also gathers people around a
vocabulary, e.g., you can ask which version a person is using more
definitively. If a person says "trunk" you have to know which
revision or when they last updated. If they say, "I updated to 0.98
and now I see HTML garbage in my website." you know it's probably
because of the auto escaping.

* 3rd party apps could more easily plan updates. For example, after
qsrf merge, django-tagging was broken. If django-tagging instead said
it worked against 0.97, there could have been a planned update to
0.98. Granted, the breakage would have still occurred for those
following trunk, but the benefits of the releases above is that the
3rd party people can claim with certainty that their code works
against a certain release, not "this works against trunk and may break
if they change their API."

* There have been a few cases where getting something in trunk to get
more eyes on the code to work on it has been beneficial. After a
point release you can merge in unstable code and get the main
developer's eyeballs fixing things (sort of like the flurry of code
coming into the Linux kernel after an official release). It sounds
like a faster iteration process to me than people not wanting to break
trunk b/c it's the norm to run production websites off of it.

I'm not arguing for the above releases or a pre 1.0 release, I'm only
trying to make some claims that frequent releases can be a good thing
for the Django ecosystem as a whole.

-Rob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Alex Koshelev]

I think that it is better way to write code and produce 1.0 as soon as
possible then to write tons of text that doesn't help in it.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

Rob, let me step back a moment and point out how this comment would
strike me if I didn't know you and didn't know that it wasn't your
inention to come off this way.

The way you've laid this out would sound as if you think that:

A) The Django dev team is unaware of these arguments, or

B) The dev team is aware of them but is willfully ignoring them.

Of course, that's not how you meant it to sound, and neither one of
those things is true, but please do keep in mind that it's one possible
reading of your statement.

Meanwhile, the thing that I, personally, feel keeps getting overlooked
is the fact that what we're really talking about here is a trade-off:
doing multiple interim pre-1.0 releases would have had advantages,
yes, but it also would have had disadvantages. For example:

* The time the dev team devotes to Django would be stretched even
further by needing to do multiple rounds of QA and support for these
releases.

* Downstream distributors would similarly face an increased workload
for these releases.

* End users would face a series of major backwards-incompatible
releases over a relatively short period of time. And this one is
really the killer, because instead of having a "here's the stable
pre-1.0 release, you can pin to it until you're ready for the jump"
policy, we'd have that release -- and the one after it -- falling
off the support policy (three releases plus trunk is tricky enough;
six releases plus trunk would be a nightmare. As a result, 0.96 and
a hypothetical 0.97 would have to lose support) and forcing upgrades
on people who didn't necessarily want them.

There would be frustration from people who want to stick to, say, the
hypothetical 0.98 but need a third-party app that forges ahead to the
hypothetical 0.99. There would be gnashing of teeth from people who
would hear that they need to upgrade and do all the QA and work to get
on a new, incompatible release, only to have to do it again in a couple
months because the third-party stuff won't stand still for them.

This last paragraph should sound familiar, by the way, because it's
really not any different from the situation of someone who wants to,
say, work on a post-autoescape but pre-qsrf Django right now.

Similarly, people would complain about having to accept
backwards-incompatible changes and further rounds of QA and upgrading
as a side effect of picking up new features or third-party
compatiblity with each release. And again, this is no different from
what people complaing about right now with trunk.

Which brings this back to being a trade-off. The decision that's been
made does incur one set of downsides, yes, but it avoids
another set. And it introduces a certain simplicity to deployment
choices:

* If your primary concern is stability and compatibility rather than
features, 0.96 is stable and supported and you should use it.

* If you're more interested in getting access to new features, and
for your project's needs that outweights the cost of wading into a
moving target, you can snapshot trunk and run off that.

And when 1.0 lands, both groups have a clear, single-step upgrade
process to get onto the final 1.0 codebase.

I think that's the better plan by far, and that's why I thought and
still think that we should stick to it: of the available trade-offs we
can make, I think this is the one that results in the least amount of
wailing and gnashing of teeth on the part of everyone involved.

[J. Cliff Dyer]

Post by James Bennett
There would be frustration from people who want to stick to, say, the
hypothetical 0.98 but need a third-party app that forges ahead to the
hypothetical 0.99. There would be gnashing of teeth from people who
would hear that they need to upgrade and do all the QA and work to get
on a new, incompatible release, only to have to do it again in a couple
months because the third-party stuff won't stand still for them.

I agree with the sentiment of this, but we've passed the point where
it's a useful argument.

* A year and a half (with still a major branch to be committed before
1.0 lands and no release date in sight) is *not* too frequently to have
a couple incompatible updates. The longer the stretch before 1.0, the
less true this argument becomes.
* Further nobody is going to be forced to update just because it has a
number on it any more than they're forced to keep up with trunk. In
fact, there will be less pressure to update, because security patches
will be backported.
* The only exception is, as you mention people who are relying on third
party apps, but this doesn't hold water either, because many third party
apps are actually based on trunk (or worse! branches of trunk).

I do see from Adrian's post above that there is some rethinking of the
release schedule going on now. As you said, there's a trade-off to be
had with releasing now and holding off to 1.0, but as the interval
stretches out, the balance shifts toward the need to release, and maybe
we've reached the threshold where the problems with the current release
plan are starting to outweigh the benefits. We'll see.

Cheers,
Cliff


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

Post by J. Cliff Dyer
I agree with the sentiment of this, but we've passed the point where
it's a useful argument.

I'll concede that if you'll concede that we've also passed the point
where issuing interim pre-1.0 releases offers any real gain over
finishing 1.0 ;)

Post by J. Cliff Dyer
* A year and a half (with still a major branch to be committed before
1.0 lands and no release date in sight) is *not* too frequently to have
a couple incompatible updates. The longer the stretch before 1.0, the
less true this argument becomes.

People have been saying that they'd like to see, for example, a
six-month release schedule. That's about the shortest that's
practicable in terms of expecting people to go through the upgrade
process. But since this time last year, I count the equivalent of four
major breaking (in the sense of either "loses backwards compatibility,
or otherwise requires significant effort to port across) changes and a
fifth is on the way. Assuming, as I hope it will, the newforms-admin
is done within the next couple of months, that's equivalent to a
"release cycle" of 2-3 months with a non-trivial upgrade process along
the way.

So following several folks' suggestion of releasing every time a big
breaker lands would have pushed us through 0.97, 0.98, 0.99 and
probably two more *pre-1.0* non-trivial upgrade processes in just over
a year. I don't see that as a smart thing to do.

Post by J. Cliff Dyer
* Further nobody is going to be forced to update just because it has a
number on it any more than they're forced to keep up with trunk.

In a "release early, release often" scheme, yes they will, because --
as I've pointed out already -- such a scheme would push at least two
releases over the support cliff. Plus, third-party apps would likely
track the latest stable release on a faster schedule, which means that
there would be no alleviation of the "I'm on Django xxxx and the app I
want to use is on Django yyyy" problem people have complained about.

Post by J. Cliff Dyer
In
fact, there will be less pressure to update, because security patches
will be backported.

Nope. At the very least, 0.96 and a hypothetical 0.97 would lose
support before 1.0, and potentially (depending on how aggressive a
hypothetical release schedule you want) a hypothetical 0.98 would lose
support too. And no support == time to upgrade.

Post by J. Cliff Dyer
* The only exception is, as you mention people who are relying on third
party apps, but this doesn't hold water either, because many third party
apps are actually based on trunk (or worse! branches of trunk).

My point about third-party apps is simply to note that more frequent
releases would not alleviate versioning issues with third-party apps.
"My codebase and apps are written for pre-autoescape trunk but this
third-party app I need is written for post-qsrf trunk" is
fundamentally no different from "my codebase and apps are written for
Django 0.97, but this third-party app I need is written for Django
0.99". In other words, more frequent releases do not solve this
problem (unless of course, we're talking about 1.x releases where
compatibility within the line would be maintained).

Post by J. Cliff Dyer
I do see from Adrian's post above that there is some rethinking of the
release schedule going on now.

If so, I missed it; I don't see anything from Adrian in this thread.

Post by J. Cliff Dyer
As you said, there's a trade-off to be
had with releasing now and holding off to 1.0, but as the interval
stretches out, the balance shifts toward the need to release, and maybe
we've reached the threshold where the problems with the current release
plan are starting to outweigh the benefits.

At this point, I don't see any possible gain to be had. With one
large-scale item left to land on the 1.0 checklist (everything else is
smaller and/or more distributed in terms of workload and/or doesn't
involve breaking changes) and with development ramping up on that item
(newforms-admin) to get it done, I don't see how an interim release
would be anything other than a slap in users' faces: "OK, you begged
for a release before 1.0, so here it is, so close to the time of 1.0
that it's practically pointless."

[J. Cliff Dyer]

Post by James Bennett

Post by J. Cliff Dyer
I agree with the sentiment of this, but we've passed the point where
it's a useful argument.

I'll concede that if you'll concede that we've also passed the point
where issuing interim pre-1.0 releases offers any real gain over
finishing 1.0 ;)

I'm willing to be convinced, but it depends on how far out that release
is. As of now there's no release date.

You've said that the pain of upgrading is too great if we're just going
to supercede it in a few months. So if you are confident that we're not
much more than three months from being in 1.0 pre-releases, then I'll
keep quiet, and see what I can do to help out with getting features
landed. On the other hand, if our current status is "Maybe Three
Months, Maybe Nine Months," it might be worth the risk of an interim
release.

Cheers,
Cliff



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Deryck Hodge]

Hi, all.

Post by J. Cliff Dyer

Post by James Bennett

Post by J. Cliff Dyer
I agree with the sentiment of this, but we've passed the point where
it's a useful argument.

I'll concede that if you'll concede that we've also passed the point
where issuing interim pre-1.0 releases offers any real gain over
finishing 1.0 ;)

I'm willing to be convinced, but it depends on how far out that release
is. As of now there's no release date.

It seems to me this conversations is drifting toward the all or none
approach -- wait until 1.0 lands vs. six month/incremental releases.
Can we not consider a middle ground? If new-forms-admin is 6 months
or a year from landing, then why not a single release now to get a
more current release out? I know there is some feeling that a release
just adds work at this point with little benefit, but I could see the
point of a single release to catch recent big changes and allow Django
users to upgrade in a couple steps rather than large backwards
compatible break that 1.0 is likely to be.

As I said earlier, I can go either way on this discussion. I see
valid points from all the arguments. I fully support James, Jacob, et
al on wanting to wait until 1.0, but at the same time, what's the harm
in a single release until then? Not just to quiet the nay-sayers, but
many, many people just don't notice the activity going on in Django
without a release to call attention to it.

Cheers,
deryck
--
Deryck Hodge
http://www.devurandom.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Tai Lee]

Personally I loosely follow trunk so I'm not waiting for 1.0, and I
don't really care how many "releases" there are between now and 1.0.
What I would like to see is the last few major NFA blockers fixed and
NFA merged into trunk. Just get it out there in trunk, so we can get
more real world use reports and start refining it.

In general I do think that the Django release cycle is a bit long in
the tooth. The longer we wait between releases the harder upgrading
becomes for users who want to track a stable Django. If I weren't
following trunk, I'd like to see a "stable" release at least every 6
months. Unicode, QSRF, NFA, are all sufficiently significant changes
to warrant a release.

I'd rather have the option of upgrading and dealing with backwards
compatibility problems for each of those issues one at a time, (or all
at once if I skip a release), than waiting a year and a half for 1.0
to drop with numerous major backwards incompatible changes.

Providing "unsupported" snapshots when major functionality (unicode,
qsrf) hits trunk would be nice and shouldn't be a massive time sink
for the developers. I don't see how this is any different from asking
people to grab trunk using SVN - it's just in tarball form at specific
milestones.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[J. Cliff Dyer]

Apologies for posting before I finished reading.

Post by James Bennett

Post by J. Cliff Dyer
I agree with the sentiment of this, but we've passed the point where
it's a useful argument.

I'll concede that if you'll concede that we've also passed the point
where issuing interim pre-1.0 releases offers any real gain over
finishing 1.0 ;)

Post by J. Cliff Dyer
* A year and a half (with still a major branch to be committed before
1.0 lands and no release date in sight) is *not* too frequently to have
a couple incompatible updates. The longer the stretch before 1.0, the
less true this argument becomes.

People have been saying that they'd like to see, for example, a
six-month release schedule. That's about the shortest that's
practicable in terms of expecting people to go through the upgrade
process. But since this time last year, I count the equivalent of four
major breaking (in the sense of either "loses backwards compatibility,
or otherwise requires significant effort to port across) changes and a
fifth is on the way. Assuming, as I hope it will, the newforms-admin
is done within the next couple of months, that's equivalent to a
"release cycle" of 2-3 months with a non-trivial upgrade process along
the way.

As mentioned in my previous post, if it's indeed three months, I agree,
but if it's only "hopefully" three months, then do we want to end up six
or nine months out still waiting for 1.0 to land "in a couple months?"

The tension seems to be, how hard to we push for 1.0, especially as
regards NFA? Are there only two options? To release 1.0 on a firm
deadline regardless of the state of NFA or to hold off until NFA is
released regardless of how long that takes?

Both options have risks. Maybe balance the risks by shooting for (e.g.)
two months, with a firm deadline of releasing 1.0 regardless if another
five months pass without NFA. Just a thought. Both 1.0 without NFA and
no 1.0 for a year sound pretty horrifying to me.

Post by James Bennett
So following several folks' suggestion of releasing every time a big
breaker lands would have pushed us through 0.97, 0.98, 0.99 and
probably two more *pre-1.0* non-trivial upgrade processes in just over
a year. I don't see that as a smart thing to do.

Agreed. But that suggestion is not the only alternative; a six month
compromise would not have been out of the question. (of course
hindsight is 20/20 and all, but lets take that hindsight and look
forward).

Post by James Bennett

Post by J. Cliff Dyer
* Further nobody is going to be forced to update just because it has a
number on it any more than they're forced to keep up with trunk.

In a "release early, release often" scheme, yes they will, because --
as I've pointed out already -- such a scheme would push at least two
releases over the support cliff. Plus, third-party apps would likely
track the latest stable release on a faster schedule, which means that
there would be no alleviation of the "I'm on Django xxxx and the app I
want to use is on Django yyyy" problem people have complained about.

Post by J. Cliff Dyer
In
fact, there will be less pressure to update, because security patches
will be backported.

Nope. At the very least, 0.96 and a hypothetical 0.97 would lose
support before 1.0, and potentially (depending on how aggressive a
hypothetical release schedule you want) a hypothetical 0.98 would lose
support too. And no support == time to upgrade.

Maybe that policy should be looked at? Obviously there are limited
resources for maintaining security patches, but it would be easier to
organize a grassroots effort for the community to support backporting
security patches to a hypothetically-obsolete older release or two, and
sharing it with the community than it would be to ask everyone running
an older trunk to create backport their own patches.

Post by James Bennett

Post by J. Cliff Dyer
* The only exception is, as you mention people who are relying on third
party apps, but this doesn't hold water either, because many third party
apps are actually based on trunk (or worse! branches of trunk).

My point about third-party apps is simply to note that more frequent
releases would not alleviate versioning issues with third-party apps.
"My codebase and apps are written for pre-autoescape trunk but this
third-party app I need is written for post-qsrf trunk" is
fundamentally no different from "my codebase and apps are written for
Django 0.97, but this third-party app I need is written for Django
0.99". In other words, more frequent releases do not solve this
problem (unless of course, we're talking about 1.x releases where
compatibility within the line would be maintained).

Agreed, except that there are fewer targets. My point was that frequent
releases are not *causing* this problem. The problem already exists.

Post by James Bennett

Post by J. Cliff Dyer
I do see from Adrian's post above that there is some rethinking of the
release schedule going on now.

If so, I missed it; I don't see anything from Adrian in this thread.

Heh. My mistake. It was Jacob. Proposing "train releases."

Post by James Bennett

Post by J. Cliff Dyer
As you said, there's a trade-off to be
had with releasing now and holding off to 1.0, but as the interval
stretches out, the balance shifts toward the need to release, and maybe
we've reached the threshold where the problems with the current release
plan are starting to outweigh the benefits.

At this point, I don't see any possible gain to be had. With one
large-scale item left to land on the 1.0 checklist (everything else is
smaller and/or more distributed in terms of workload and/or doesn't
involve breaking changes) and with development ramping up on that item
(newforms-admin) to get it done, I don't see how an interim release
would be anything other than a slap in users' faces: "OK, you begged
for a release before 1.0, so here it is, so close to the time of 1.0
that it's practically pointless."

Again, I'll buy that argument if we can really push 1.0 in the short
term. My concern is that this has been one of the arguments for
avoiding 0.97 before. Of course the closer we get to release, the truer
it gets, but also the more evident it becomes that it wasn't *really*
true before (when we were still 12 months away from 1.0, for example).

I'll start poking my nose into NFA to see what I can do to help.

Cheers,
Cliff





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

Post by J. Cliff Dyer
As mentioned in my previous post, if it's indeed three months, I agree,
but if it's only "hopefully" three months, then do we want to end up six
or nine months out still waiting for 1.0 to land "in a couple months?"

Well, nfa is doing pretty well; as others have mentioned, it's at or
near parity (functionality-wise) with the current admin, and
incidentally has already fixed quite a lot of bugs which hamper the
current admin. So even a pessimistic estimate would have to concede
that it's quite close, and it's the last huge change to land before
1.0, which in turn means that by the time we'd get back to normal
development after doing QA and everything for an interim release, we
could instead be doing 1.0 alphas or betas.

(and note that I'm not relying on any secret insider information in
saying this, because there isn't any; I just pay attention to what's
going on publicly)

Post by J. Cliff Dyer
Maybe that policy should be looked at? Obviously there are limited
resources for maintaining security patches, but it would be easier to
organize a grassroots effort for the community to support backporting
security patches to a hypothetically-obsolete older release or two, and
sharing it with the community than it would be to ask everyone running
an older trunk to create backport their own patches.

I personally wouldn't have any problem with keeping a branch or two
alive and giving a couple trusted community folks commit bits on it if
they want to maintain support past the official period for a release.
But like all things, that would take time to get going, and since I've
already pointed out that on a "release when a big thing finishes"
schedule we'd probably be kicking out releases far too quickly for any
such effort to keep up (having to hunt up new community maintainers
every couple months probably wouldn't have worked).

Post by J. Cliff Dyer
Agreed, except that there are fewer targets. My point was that frequent
releases are not *causing* this problem. The problem already exists.

Not really, no; there'd be just as many targets, only they'd have
different names ("Django 0.98" instead of "QSRF merge", for example).

Post by J. Cliff Dyer
Again, I'll buy that argument if we can really push 1.0 in the short
term. My concern is that this has been one of the arguments for
avoiding 0.97 before. Of course the closer we get to release, the truer
it gets, but also the more evident it becomes that it wasn't *really*
true before (when we were still 12 months away from 1.0, for example).

Keep in mind that, twelve months ago, 0.96 wasn't even six months old.

At any rate, Jacob's already mentioned he'll be posting quite a lot of
information quite soon; it'll largely just be collating a lot of
already-available information into one document and slapping some
projected dates on it, but perhaps that'll help a bit.

[Jarek Zgoda]

Yes, we will have problem. And we will not port our apps to 1.0.

I'm in the same situation. And I know we'll never go for 1.0 when it
will be ready, because there will be too much work to port all the
applications through unicode, qs-rf and nfa changes. We will stay with
0.96 until customer drops the project or we say "no more work on
this". That's the bad thing on not having interim releases focused on
single feature.

I personally know many people still running their sites on 0.91
because magic-removal was too painfull to follow. You can cite me, I'm
predicting most of projects currently deployed on 0.96 will stay on
0.96 until natural death.

Post by Jeremy Dunck
...

Post by Rob Hudson
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 techniques
to make automated porting work.  Otherwise, you're going to have a
painful legacy  problem.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Andrew Durdin]

Post by Rob Hudson
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 and all at various phases of development.
We don't have the resources to continuously update all of them to
trunk and fix the various backward incompatible changes that might
crop up, and each one can't be on its own trunk release or trying to
assemble any sort of library would be a nightmare.  Not even
mentioning having to support various Django releases on our production
servers.  So we're stuck on 0.96 until 1.0 comes along.

This is much the same where I work. We're using our own fork of 0.96
with a handful of cherry-picked changes that were particularly
important for us backported from trunk. I'm really looking forward to
moving to 1.0 when it's released (possibly even when there's a release
candidate), particularly for QSRF and the full unicode support
throughout.

Speaking of sprints, are there any plans to hold a Django sprint
during Europython 2008 (only one month away now)?

Andrew.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jannis Leidel]

Post by Andrew Durdin
Speaking of sprints, are there any plans to hold a Django sprint
during Europython 2008 (only one month away now)?

I added Django to the Sprint Suggestions page in the Europython wiki
[1] some time ago and remember Jacob agreeing that it's a good idea.
The sprint days are "from Thursday 10th July until Saturday 12th July
(three whole days)".

Although I'm sure there are a lot people willing to work remotely I
wonder if there are other people coming to Europython?

Cheers,
Jannis/jezdez

1: http://europython.org/Sprint%20Suggestions

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Brian Rosner]

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

+1. I think this needs to happen to the Django release cycle in
general. I think it is a good way to keep developers motivated to
complete features and continually get releases out the door. The
Django trunk needs to be place were we can dump these features and get
constant feedback from the community of those who want to keep up with
the bleeding edge.

newforms-admin only has a few "absolutely have to have done before a
merge" items IMO. The rest of the nfa-blockers can be dealt with on
trunk. It is already a big enough backward-incompatible change that
people will be having to do the changes or wait to find time. I think
that newforms-admin needs to land as soon as possible. The whole idea
of newforms-admin has been accomplished. The admin is using newforms.
There are a ton of hooks. The rest can be worked on with the full
Django core team and the many contributors in the community.

Brian Rosner
http://oebfare.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[a***@public.gmane.org]

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 few weeks we snapshot trunk and offer it on the
downloads page as a known stable release, and in the interim there is
no guarantee that it will be stable. I'm not sure how much sense that
makes in the context of a push towards 1.0, however in general it
seems like a good balance of stability and bleeding-edge(as long as it
is understood that those aren't numbered releases, just development
snapshots).

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

+1. I think this needs to happen to the Django release cycle in  
general. I think it is a good way to keep developers motivated to  
complete features and continually get releases out the door. The  
Django trunk needs to be place were we can dump these features and get  
constant feedback from the community of those who want to keep up with  
the bleeding edge.
newforms-admin only has a few "absolutely have to have done before a  
merge" items IMO. The rest of the nfa-blockers can be dealt with on  
trunk. It is already a big enough backward-incompatible change that  
people will be having to do the changes or wait to find time. I think  
that newforms-admin needs to land as soon as possible. The whole idea  
of newforms-admin has been accomplished. The admin is using newforms.  
There are a ton of hooks. The rest can be worked on with the full  
Django core team and the many contributors in the community.
Brian Rosnerhttp://oebfare.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[antonis]

Release an interim version because 0.96 is getting stale.
Leave newforms admin out because its taking forever.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

vote(-(sys.maxint))

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 doing a trunk merge to get more eyeballs on the code, then
let's do that instead.

[Nathaniel Whiteinge]

Post by James Bennett
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 doing a trunk merge to get more eyeballs on the code, then
let's do that instead.

Hear hear! I think this is a really important step forward, as well as
a really import step for the public eye. A newforms-admin themed
sprint may be the impetus needed to help the project not look so
stalled.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Julien]

Post by James Bennett
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 doing a trunk merge to get more eyeballs on the code, then
let's do that instead.

I like the sprint idea. In general, I think there should first be a
debate as to what features should be included in the following release
(I know there's been quite a few post about 1.0 already). Then, the
core team would select the most important ones and organize specific
sprints to get those sorted.

If newforms-admin has been identified as the sine-qua-non feature for
1.0, then shall we organize a sprint just for it? Also, would that be
technically possible and actually productive? Maybe having dozens of
people working on it at the same time would be overkill...?

I know it's not as simple as that ("Do a sprint and sort it out"), but
maybe that's an idea worth digging into.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

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 post-0.96 feature would just turn around
and complain that they need stability and wish we'd stop pushing
releases with big changes in them.

There's really nothing we can do that'll make those folks happy, so
I'd vote for continuing on the path toward 1.0.

[Deryck Hodge]

Hi, all.

Post by James Bennett
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 post-0.96 feature would just turn around
and complain that they need stability and wish we'd stop pushing
releases with big changes in them.
There's really nothing we can do that'll make those folks happy, so
I'd vote for continuing on the path toward 1.0.

While I personally can go either way on this particular issue -- i.e.
I see the point of regular releases, timed release, or waiting until
feature complete for 1.0 -- I do think James is tending toward the
cynical on this a bit. No offense meant to James.

I do agree that release numbers often have too much weight attributed
to them, but there really is *some* value in them. If nothing else,
you can build community around a release in a way that you can't
running against trunk. And also, I think the larger point of some of
this discussion is that it's been over a year since .96, and if it's
still going to be a while to 1.0, some feel an intermediate release
could be useful.

Again, I understand limited developer resources, and I get open source
projects having to put effort where is most practical. I think that
argument is enough, without trying to lump everyone together who would
like to see another release in the near term as "haters" who are going
to be disappointed no matter what happens. I know those people exist,
but I don't everyone who expresses concerns or questions is
necessarily that kind of person.

Cheers,
deryck
--
Deryck Hodge
http://www.devurandom.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jeremy Dunck]

On Sat, Jun 7, 2008 at 6:17 PM, James Bennett <ubernostrum-***@public.gmane.org> 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 NFA and has done nothing to help it
along, I'd be happy to contribute to an NFA-focused sprint.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Ivan Sagalaev]

Post by James Bennett
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.

+1 for early merging. Merging qs-rf helped (forced :-) ) many people to
catch many bugs that won't ever be found on the branch due to lack of
attention.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[John D'Agostino]

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

-1 on this for version 1.0.

I think it is essential that django ships its first major version with
newforms-admin. Version 1.0 is going to be the first version that "we"
as a community market to a wider audience. People may have the
opinion that newforms isn't as great as we say it is (and know it is)
if we can't ship our showcase application without it using newforms.
Maybe another sprint is in order?

Post by Jacob Kaplan-Moss
With newforms-admin, there's not only a great increase in the power of the
admin app itself, but it's also a demonstration of best practices for
creating generic apps with Django.

I am +1 on moving to a date based release cycle after version 1.0 as
others have stated it has worked well for large open source projects
like Ubuntu and Gnome.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Russell Keith-Magee]

On Sun, Jun 8, 2008 at 3:06 AM, Jacob Kaplan-Moss

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

-1, for now at least. IMHO, we simply cannot release a v1.0 that has
oldforms in it, and without the merge of newforms-admin, we're not
going to be able to do that.

Newforms-admin is the last piece in an important cycle of refactoring
that has been going on since Django was originally open sourced.
Magic-removal cleaned up model defintions, the query syntax, and some
model loading issues. Queryset-refactor cleaned up the query
internals. Newforms cleaned up manipulator/oldforms. Newforms-admin
completes the newforms transition.

Once NFA is done, I can't really think of an area of Django that will
require wholesale change - there are lots of improvements that can be
made, but they should be incremental, rather than massive. For those
sorts of changes, train-schedule releases are ideal. However, we need
a solid foundation to work on.

As for getting the work done - I've been distracted for most of this
year, but I'm starting to get some free time again. I have been
working though a backlog of little tickets. However, most of these are
minor feature enhancements. I'm happy to put those on hold and work on
newforms-admin instead so we can get this monkey off our backs.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Justin Bronn]

For the record, I'm -1 on releasing 1.0 without NFA.

As I've discussed with Jacob and Adrian, GeoDjango will be merged with
trunk at some point in the future. In my opinion, there's nothing
preventing it from being included in the 1.0 release (I'm currently
addressing the biggest hurdle, documentation, by porting over the wiki
contents to ReST [1]). One of my best features, the geographic admin,
depends on NFA [2]; thus, I'm willing to devote significant
development time to getting NFA merged.

A Django 1.0 with newforms-admin + gis is a compelling release -- it
would put all those serving haterade in their proper place.

[1] http://geodjango.org/hg/gis-docs
[2] http://geodjango.org/hg/gis-newforms
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Wim Feijen]

Jacob, I am very glad this discussion is being held, and with such
good arguments.

My vote is +1, because I think Django needs another stable release
right now. Fortunately, the trunk is stable (thank you!). Rob says
that it is good for a software project to have regular releases on a
half-year basis and I totally agree. This gives everyone the
opportunity to use a recent version of Django. Right now,
unfortunately, people with strong demands on stability, have to revert
to an outdated Django 0.96 or take a risk using Django trunk, which
feels like a choice between two wrongs.

Personally, I would be very happy to use a Django 1.0, with or without
newforms, just as it happens. And considering the posts, just having
this discussion already seems to motivate people into action! :)

Wim

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[George Vilches]

Post by Wim Feijen
Fortunately, the trunk is stable (thank you!).

I think what people are missing most here is that this statement is
moderately inaccurate. Since QSRF, there have been a significant
number of data-fetching related tickets that are relatively easy to
hit that have not yet been resolved. This is no one's fault, Malcolm
had real life come up, and there are very few people capable of
replacing him right now. This is also not to disparage Django's
quality of trunk code (which is very high), QSRF was a *very* large
merge, it was impossible that things were not going to need review
after release to such a wide audience.

I'm attempting to pick up the slack at least in part, but we have
several tickets that range from easy to identify and solve to rather
complicated for things that are relatively common database use cases.
Here's a smattering of those tickets (I do not promise that I have
verified every one of these, just some, the rest were from a grazing
of the ticket system for things that looked similar to problems I've
encountered):

http://code.djangoproject.com/ticket/7378 - Reverse relationship
ignores to_field (in another setting)
http://code.djangoproject.com/ticket/7372 - queryset intersection
either returns wrong result or raises KeyError depending on order
(after queryset-refactor merge)
http://code.djangoproject.com/ticket/7371 - Missing FROM table from
autogenerated SQL throws error
http://code.djangoproject.com/ticket/7369 - ForeignKey non-null
relationship after null relationship on select_related() generates
invalid query
http://code.djangoproject.com/ticket/7367 - Cannot have non-primary-
key OneToOneField to parent class
http://code.djangoproject.com/ticket/7330 - Filtering on multiple
indirect relations to same table gives incorrect SQL
http://code.djangoproject.com/ticket/7277 - after queryset refactor,
specifying > 2 OR'ed conditions that span many-to-many relationships
returns broken SQL
http://code.djangoproject.com/ticket/7125 - Multiple ForeignKeys to
the same model produces wrong SQL statements.

Now, I'm putting my money where my mouth is, and am working to
understand the flow of the internal query API so that I can generate
patches for most of these tickets, as something we're working on over
here requires some deep integration into the SQL layer (better
selectability on OneToOneFields). That aside, now that QSRF is
getting a real fleshing-out and all these reports are trickling in, I
think it would be a bad idea to stamp a version right now until either
someone can step up and fill Malcolm's shoes as a queryset maintainer,
or he becomes available once again from real life.

Thanks,
George


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Justin Bronn]

That aside, now that QSRF is  
getting a real fleshing-out and all these reports are trickling in, I  
think it would be a bad idea to stamp a version right now until either  
someone can step up and fill Malcolm's shoes as a queryset maintainer,  
or he becomes available once again from real life.

There's no way I can fill Malcolm's shoes, but I've been intimately
working with the qsrf code since November so I know it pretty well.
I'll be glad to take a look at some of these tickets and see what I
can do. Feel free to contact me off-list and/or on IRC if you wanna
poke my brain about this stuff.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Phil M]

Post by Wim Feijen
My vote is +1, because I think Django needs another stable release
right now. Fortunately, the trunk is stable (thank you!). Rob says
that it is good for a software project to have regular releases on a
half-year basis and I totally agree. This gives everyone the
opportunity to use a recent version of Django. Right now,
unfortunately, people with strong demands on stability, have to revert
to an outdated Django 0.96 or take a risk using Django trunk, which
feels like a choice between two wrongs.
Personally, I would be very happy to use a Django 1.0, with or without
newforms, just as it happens. And considering the posts, just having
this discussion already seems to motivate people into action! :)

Quite a few Django projects are using the trunk version instead of the
stable version for their addons, which is annoying for me running the
stable version. The problem is that Django has been so long without a
release that the stable version is now a stale version - it reminds me
of Debian taking so long with their releases.

Every once in a while a release is needed for all the developers to
group together on a common target, instead of being forced to pick
between 0.96 and trunk. I'm not looking for a 1.0 release, just
something to keep developers going with a release until 1.0 is ready.
At the moment people are forced to pick between stale and trunk, which
ends up with more people picking trunk.

The longer you leave it, more incompatible changes are going to be
introduced between 0.96 and 1.0. If a release is made between then it
gives people a chance to update their sites to fix any problems with
compatability, as well as a chance to play with some of the new
features.











--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Justin Lilly]

The longer you leave it, more incompatible changes are going to be
introduced between 0.96 and 1.0. If a release is made between then it
gives people a chance to update their sites to fix any problems with
compatability, as well as a chance to play with some of the new
features.


I think this is the part people want to avoid. What the devs keep echoing is
that it's uncool to have people take their.96 code and go through all of
their backwards incompatible changes to get it up to a .97 release only to
have to do the same thing when NFA lands. I think if you're itching for a
release, dive into the nfa code and get to work. That's going to be the
quickest path to a release, not belly-aching over it on this list.

-justin

Post by Phil M

Post by Wim Feijen
My vote is +1, because I think Django needs another stable release
right now. Fortunately, the trunk is stable (thank you!). Rob says
that it is good for a software project to have regular releases on a
half-year basis and I totally agree. This gives everyone the
opportunity to use a recent version of Django. Right now,
unfortunately, people with strong demands on stability, have to revert
to an outdated Django 0.96 or take a risk using Django trunk, which
feels like a choice between two wrongs.
Personally, I would be very happy to use a Django 1.0, with or without
newforms, just as it happens. And considering the posts, just having
this discussion already seems to motivate people into action! :)

Quite a few Django projects are using the trunk version instead of the
stable version for their addons, which is annoying for me running the
stable version. The problem is that Django has been so long without a
release that the stable version is now a stale version - it reminds me
of Debian taking so long with their releases.
Every once in a while a release is needed for all the developers to
group together on a common target, instead of being forced to pick
between 0.96 and trunk. I'm not looking for a 1.0 release, just
something to keep developers going with a release until 1.0 is ready.
At the moment people are forced to pick between stale and trunk, which
ends up with more people picking trunk.
The longer you leave it, more incompatible changes are going to be
introduced between 0.96 and 1.0. If a release is made between then it
gives people a chance to update their sites to fix any problems with
compatability, as well as a chance to play with some of the new
features.

--
Justin Lilly
Web Developer/Designer
http://justinlilly.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Ashish]

my proposal is
1) core developers decide an absolute minimum features that needs to
be implemented to get to 1.0 rc and FREEZE it. Push all other features
out beyond 1.0. Ignore any other requests.
2) Focus on only those features and any critical bugs.
3) Between 1.0 rc and 1.0 final/ga do only bug fixes and no new
feature release.
4) PUBLISH a plan to reach 1.0 ga/final. Do not be aggressive. Make
commitments you can live with.
5) Give community regular updates on progress and request for help.
6) any one starts these threads again refer them to the plan. Core
developers time is better spent coding than answering these threads
again and again.

I know this is not open source way of it happens when it happens. But
putting some structure and plan will help everyone given the choices
and compitition in todays open source marketplace for web frameworks.

Lack of visibility on what is going on with 1.0 and over an year delay
on 1.0 (perceived) is causing people to get frustated and we see these
discussions threads every few weeks now.

We all understand that it is totally volunteer run project and people
are doing work on django in addition to their regular jobs and family
life. It is very hard to estimate in software even when you are
working full time let alone part time.

We all appreciate the great work core developers are doing and we all
want django to be a huge success.

thanks
Ashish

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

Post by Ashish
my proposal is

You do know that a list of what has to happen before 1.0, and a page
listing the status of each item, has been available for quite some
time, right? I

Post by Ashish
Lack of visibility on what is going on with 1.0 and over an year delay
on 1.0 (perceived) is causing people to get frustated and we see these
discussions threads every few weeks now.

I'm really, honestly baffled by this statement. Django development
happens in the open. Always has. Anyone anywhere at any time can look
at what's going on, see what the dev team is talking about, etc. And
it's not like the places where the discussion happen are a super top
secret; a link to the dev list is publicly advertised on
djangoproject.com, as is the bug tracker and wiki.

So please, in all honesty, tell me why you think Django's development
process isn't "visible" enough for people who are concerned and want
to get information. If there's a genuine issue I'm missing here, I'd
love to correct it.

[Ashish]

I have read threads on 1.0 , some one more than an year old and some
very recent. I see exactly same issues being discussed. 1.0 has been
discussed for way too long. Get past it.

Thats why I proposed "publishing a plan and freezing the scope and
hitting it. " see details on earlier post in this thread. You have to
decide on a date and get it out. Just cannot infinitely wait for that
elusive perfection - perfect list of features and perfect code. ( If
you have ever managed developers you would know what I am talking
about.)

as far as list for 1.0 goes , read this thread,

http://groups.google.com/group/django-developers/msg/c2be209a9f10ff30


In short all I am looking for is commitment to " freezing the scope,
publishing a plan and hitting it for 1.0 " That will greatly increase
the community's trust.

lack of visibility i talked about was about reaching the 1.0 milestone
and not the code changes or discussions.

Ashish

Post by James Bennett

 my proposal is

You do know that a list of what has to happen before 1.0, and a page
listing the status of each item, has been available for quite some
time, right? I

Lack of visibility on what is going on with 1.0 and over an year delay
on 1.0 (perceived) is causing people to get frustated and we see these
discussions threads every few weeks now.

I'm really, honestly baffled by this statement. Django development
happens in the open. Always has. Anyone anywhere at any time can look
at what's going on, see what the dev team is talking about, etc. And
it's not like the places where the discussion happen are a super top
secret; a link to the dev list is publicly advertised on
djangoproject.com, as is the bug tracker and wiki.
So please, in all honesty, tell me why you think Django's development
process isn't "visible" enough for people who are concerned and want
to get information. If there's a genuine issue I'm missing here, I'd
love to correct it.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

Post by Ashish
In short all I am looking for is commitment to " freezing the scope,
publishing a plan and hitting it for 1.0 " That will greatly increase
the community's trust.

Er. You linked to a well-known thread in which the plan for 1.0 was
published; do you mean to say that this is evidence that there is no
publicly-available plan for 1.0 (which is self-contradictory), or have
I disastrously missed something?

[Peter Melvyn]

Post by James Bennett
So please, in all honesty, tell me why you think Django's development
process isn't "visible" enough for people who are concerned and want
to get information.

I give you example: few weeks ago I discovered that problem #3030
still persists: somebody fixed it by introducing
DatabaseFeatures.autoindexes_primary_keys, but left its value in the
backend.mysql.base to be False, hence the fix has no effect...

If I was asking why, there is no answer, so I don't know what
development process is behind, whether:

- everybody just fucks me off
- nobody cares about MySQL
- nobody knows
- it is an intention
- it is easiness
- will anobody fix it
- should I fix it
- etc...

###

And there is more examples...

###

Concerning the original topic: asking for frequent releases, it is
IMHO similiar as with those 'checkbox features' mentioned by Joel
Spolsky http://www.joelonsoftware.com/articles/fog0000000339.html

Peter

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Ian Kelly]

Post by Peter Melvyn

Post by James Bennett
So please, in all honesty, tell me why you think Django's development
process isn't "visible" enough for people who are concerned and want
to get information.

I give you example: few weeks ago I discovered that problem #3030
still persists: somebody fixed it by introducing
DatabaseFeatures.autoindexes_primary_keys, but left its value in the
backend.mysql.base to be False, hence the fix has no effect...

Because autoindexes_primary_keys was added to support Oracle, not for
ticket #3030. I don't think we were really aware of the ticket at the
time. Where we didn't know the correct value, we left it as False to
preserve the prior behaviour, which we presumed to be correct. MySQL
is an especially complicated case due to the large differences between
multiple supported versions.

I don't know why this is so mysterious. A small amount of browsing
turns up that the code was added in revision [4916] and specifically
enabled for Oracle only to fix ticket #3743.

Post by Peter Melvyn
If I was asking why, there is no answer, so I don't know what

I for one did not see the question.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Norjee]

Post by James Bennett

 my proposal is

You do know that a list of what has to happen before 1.0, and a page
listing the status of each item, has been available for quite some
time, right? I

Lack of visibility on what is going on with 1.0 and over an year delay
on 1.0 (perceived) is causing people to get frustated and we see these
discussions threads every few weeks now.

I'm really, honestly baffled by this statement. Django development
happens in the open. Always has. Anyone anywhere at any time can look
at what's going on, see what the dev team is talking about, etc. And
it's not like the places where the discussion happen are a super top
secret; a link to the dev list is publicly advertised on
djangoproject.com, as is the bug tracker and wiki.
So please, in all honesty, tell me why you think Django's development
process isn't "visible" enough for people who are concerned and want
to get information. If there's a genuine issue I'm missing here, I'd
love to correct it.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Norjee]

Post by James Bennett
I'm really, honestly baffled by this statement. Django development
happens in the open. Always has. Anyone anywhere at any time can look
at what's going on, see what the dev team is talking about, etc. And
it's not like the places where the discussion happen are a super top
secret; a link to the dev list is publicly advertised on
djangoproject.com, as is the bug tracker and wiki.
So please, in all honesty, tell me why you think Django's development
process isn't "visible" enough for people who are concerned and want
to get information. If there's a genuine issue I'm missing here, I'd
love to correct it.

In the beginning, there were updates on the website when new features
were added to the trunk. Now, the Djangoblog (and website, as the blog
is the only "news ticker" on the website) is awfully empty of such
updates. For example that queryset-refactor has been merged to trunk
would, imho, surely have been worth an announcement. Now i read it
here, in this discussion.

I couldn't care less how the bigger changes to trunk are being
announced to the public, either by release announcements or just bare
announcements explaining the new features and gotchas. At the moment,
they are invisible (or well hidden), and i find myself honestly
surprised that there has been progress with Django in the last half
year.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Eric]

I was in discussions at work on what version to work with on a
enterprise level project with the intent of using 1.0 when it comes
out.

We discussed using 0.96, and tracking trunk. Both routes mean a lot
of maintenance.

If we stay with 0.96, that means that when 1.0 comes out there will be
a lot of work needed in order to port it to 1.0. It is inevitable
that the migration will introduce bugs into a stable product. This
seems like a poor choice.

The other choice was tracking trunk. Incremental updates and
modifications allows the road to 1.0 update to occur in piecemeal.
This prevents the need for a gigantic undertaking to port from 0.96 to
1.0. However, the introduction of bugs will still present, they are
just spread out along the history of the project.

There's an illusion of greater stability with tracking truck as
opposed to using 0.96 and porting to 1.0. With the 0.96 to 1.0 port
it will have a greater number of bugs at one time as opposed to the
same number of bugs spread over time.

With incremental updates the downtime caused by errors introduced by
following trunk will most likely be small enough to be negligible.
However, there is a aspect of the unknown in this route (which is
despised in enterprise development). You won't know if the next
update will have crippling bugs in it.

Since there is that unknown we came up with another route. This route
is a delayed trunk update, which is tracking trunk but only updating
to a revision that's a week or two old. This adds a small buffer to
prevent those the rare crippling bugs from destroying your site.

This delayed update route adds another level of stability that a team
of developers need, a common base for development. Since we're all
working on r2110 for example, we all can use that version instead of
each developer using whatever version of trunk they have updated to.
Then in two weeks, we all update to r2201 and work on that until the
next scheduled update.

I'm not certain that this route is perfect, but it seems to be a
compromise of both worlds. A little of the stability of using 0.96
without the need of a massive port when 1.0 comes out.

Eric.

Post by Phil M

Post by Wim Feijen
My vote is +1, because I think Django needs another stable release
right now. Fortunately, the trunk is stable (thank you!). Rob says
that it is good for a software project to have regularreleaseson a
half-year basis and I totally agree. This gives everyone the
opportunity to use a recent version of Django. Right now,
unfortunately, people with strong demands on stability, have to revert
to an outdated Django 0.96 or take a risk using Django trunk, which
feels like a choice between two wrongs.
Personally, I would be very happy to use a Django 1.0, with or without
newforms, just as it happens. And considering the posts, just having
this discussion already seems to motivate people into action! :)

Quite a few Django projects are using the trunk version instead of the
stable version for their addons, which is annoying for me running the
stable version.  The problem is that Django has been so long without a
release that the stable version is now a stale version - it reminds me
of Debian taking so long with theirreleases.
Every once in a while a release is needed for all the developers to
group together on a common target, instead of being forced to pick
between 0.96 and trunk.  I'm not looking for a 1.0 release, just
something to keep developers going with a release until 1.0 is ready.
At the moment people are forced to pick between stale and trunk, which
ends up with more people picking trunk.
The longer you leave it, more incompatible changes are going to be
introduced between 0.96 and 1.0.  If a release is made between then it
gives people a chance to update their sites to fix any problems with
compatability, as well as a chance to play with some of the new
features.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Peter Melvyn]

Post by Eric
I'm not certain that this route is perfect, but it seems to be a
compromise of both worlds.

We use the same approach with mean time redundancy about 1 months.

Peter

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Tom Tobin]

On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss

Post by Jacob Kaplan-Moss
* Wait for newforms-admin to be done, merge it, and release 1.0 (well,
a series of beta/rcs, then final). This has been "plan A" all along.

+1; this is The Right Thing.

Post by Jacob Kaplan-Moss
* Release an interim release right away to respond to this supposed
"outcry" for a release. I've been opposed to this all along because I
don't the quality of something released just to get folks to shut up
will be all that high. A snapshot with an "official" number will
likely do more harm than good.

-0; this is silly and wastes time, but isn't as actively harmful as ...

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

-1. Releasing 1.0 with a major feature's implementation already
depreciated seems like The Wrong Thing, no matter what project we're
talking about. Echoing others: once we're past 1.0, this sort of
aggressive timeline would be fine for minor releases.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Hilbert Schraal]

Hi all,

What I have been missing in this discussion is the definition of a
release. It is important to release in the right manner, so that it
is worth while to spend time on it.

A release could be:

1/ a tag on a specific svn version
2/ a tag on a specific svn version and accompanying branch in which
security patches are made. sub-releases are made off of this branch.
3/ a tag on a specific svn version and accompanying branch in which
security patches and bug fixes are made. No new functionality is
added! sub-releases are made off of this branch.

As far as I know, Django uses option 2. But imho, anything less than 3
is hardly worth wile. Sure, security is important, but so is stability
(API-wise and in terms of the amount of bugs) and quality.

The current latest stable release (0.96.2) does contain bugs, for
which fixes are made in the trunk. This release would have a better
quality when it would get these bug fixes. And it would be easy for
anyone running this release to upgrade to it: just install it, without
worrying about new functionality breaking the API or introducing new
bugs. People would not be 'forced' to make a private fork of Django,
or flee to the trunk, just to get some bugs fixed.


The implication of choosing for option 3 is that you have to keep
track of the versions in which a bug needs to be fixed (e.g. trunk,
0.96 and 0.95), someone needs to make the fix in the different
versions and new sub-releases need to be made of stable versions. This
means extra work and I can imagine that the core development team is
reluctant/does not have time to commit to this. But may be others do.

I hope this is somehow helpful,
Cheers,
Hilbert
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[J. Cliff Dyer]

Post by Jacob Kaplan-Moss
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.

Jacob,

I definitely understand the frustration at passive aggressive lashing
out. However, I've worked in organizations where passive aggressive
behavior was the norm, and ones where communication was clear and open,
and in ones where it wasn't. In every single case, this had to do with
how management responds to complaints. If people feel that their issues
are being responded to, gripes are aired openly, and if they don't,
there's a lot of quiet, unproductive grumbling. Without exception.

In this case, I would specifically point to things like this:

"I'm pretty sure its been stated several times on the board but there
will be no versions released between .96 and 1.0."

I don't mean to pick on one person in particular, as this has been a
pretty common tone of response to questions about the possibility of
a .97 release.

The entire point of the blog post was that this stated policy is
problematic (agree or disagree as you like), so simply stating again
that it's not going to happen without addressing the points in the
complaint is not going to make the person feel like their complaints
have been heard, so they'll take them elsewhere.

On an open source project, it's a little more complicated because it's
not always clear to everyone involved who the core developers are, but
if nobody steps in to disagree with statements like the one above, or to
clarify it with direct reference to the specific complaints it will
start to sound like the consensus of the django community.

The rest of your response (which I haven't quoted here--sorry) does
address the blogger's concerns, and is exactly how good management can
work to reduce passive aggressiveness. Kudos for it. You don't have to
do what the complainant is asking you to do, but at least make it clear
that it's being looked at.

I'm also on the fence about whether posting a blog about it is really
passive aggressive behavior. On the one hand, you're right that
django-dev is the one place where something might actually be done about
it. On the other hand, it brings people into the conversation who
aren't regulars on django-dev, which is great for getting around the
myopia that affects all groups. The conversation that took place in the
blog comments is very different from the one that's taking place here,
and not in entirely bad ways. Furthermore, imagine if the only place to
find conversation about, for example, design decisions in python were on
the python dev list. How would someone thinking about learning a new
language be able to evaluate if python were good for their needs? The
conversation that would take place on python-dev would be above their
heads, but it would still be useful information for them to have.
Surely the mailing list shouldn't be the only location for discussion
about django's great features or its faults. I don't think we'd want to
discourage people from discussing django openly on their blogs. That's
publicity.

I don't think complaining about passive-aggressive behavior will
actually discourage passive-aggressive behavior. Develop a reputation
for being responsive to user concerns (again, this doesn't mean doing
everything they ask), and the passive aggressiveness will go away.

For the record, I would vote in favor of intermediate releases primarily
because of security patches. Where I work, projects are grant funded,
which means when they're done, there is nobody who is paid to maintain
the site. They have to stand alone. If we have an older version of
trunk, we can't SVN up to get the security patch, because there's nobody
to fix backwards incompatibilities. If there's a problem with
obsoleting older versions too quickly, maybe the obsolescence policy
should be looked at (base it on time rather than version number maybe,
but that's another conversation).

Cheers,
Cliff



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Adrian Holovaty]

On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

Let's do it. I've been thinking this same thing over the past couple
of weeks. Let's get the thing out the door.

Adrian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Gábor Farkas]

Post by James Bennett
On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

Let's do it. I've been thinking this same thing over the past couple
of weeks. Let's get the thing out the door.

so model-level validation will be dropped from 1.0?

gabor

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Julien]

+1 for merging newforms-admin ASAP.

Post by Gábor Farkas

Post by James Bennett
On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

Let's do it. I've been thinking this same thing over the past couple
of weeks. Let's get the thing out the door.

so model-level validation will be dropped from 1.0?
gabor

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Julien]

And I would also organise a sprint 3-4 weeks after the merge dedicated
to fixing bugs in NFA.

Post by Julien
+1 for merging newforms-admin ASAP.

Post by Gábor Farkas

Post by James Bennett
On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

Let's do it. I've been thinking this same thing over the past couple
of weeks. Let's get the thing out the door.

so model-level validation will be dropped from 1.0?
gabor

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Karen Tracey]

On Sat, Jun 7, 2008 at 3:06 PM, Jacob Kaplan-Moss <

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.
Thoughts?

I'd trade your controversial part for an alternative: merge mewforms-admin
back to trunk now. It's been as 'usable' as old admin for months. Sure,
it's got a couple of dozen 'blocking' bugs in the tracker but none of them
are all that serious. Current admin, as you note, also has some bugs.
Trade the existing known-never-going-to-be-fixed current admin bugs for a
different set of newforms-admin bugs and get on with fixing the second set
already. Once on trunk the community's interest will be higher so you'll
get better feedback on what is and is not really important to users, more
people who might help out with actual fixes, etc.

I think it's a shame newforms-admin wasn't done in a fashion similar to
newforms -- off in its own area of trunk for people to try out as it
developed, with the old stuff still available simultaneously so as not to
cause too much disruption. But that's water under the bridge, unless it's
an idea that might be used now. If the group really thinks newforms-admin
is not ready to take the place of current admin, perhaps it could at least
be made available on trunk alongside old admin, much as both newforms and
oldforms are available on trunk. I know there are probably lots of
irritating details on getting that to work right, but maybe it's a
possibility to think about? Really, though, I think moving right on to
newforms-admin by merging it to trunk is what should be done.

Releasing a "1.0" without newforms-admin would, I think, be a huge mistake.
I thought the promise of "1.0" was stability -- no more
backwards-incompatible changes. Don't you completely renege on that promise
if you release a "1.0" with a major component that is going to be replaced
in a entirely non-backwards-compatible way some time down the road?

Karen

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[George Vilches]

Post by Karen Tracey
I'd trade your controversial part for an alternative: merge mewforms-
admin back to trunk now. It's been as 'usable' as old admin for
months. Sure, it's got a couple of dozen 'blocking' bugs in the
tracker but none of them are all that serious. Current admin, as
you note, also has some bugs. Trade the existing known-never-going-
to-be-fixed current admin bugs for a different set of newforms-admin
bugs and get on with fixing the second set already. Once on trunk
the community's interest will be higher so you'll get better
feedback on what is and is not really important to users, more
people who might help out with actual fixes, etc.

Hear hear, I'm definitely +1 on this, for exactly Karen's reasons. I
spend a lot of time tinkering on trunk, but I don't usually have
enough time where I could easily track on two separate branches. When
a problem hits me in the face, I work on it, I don't go looking for
new ones...well, most of the time. :)

George

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[J. Clifford Dyer]

Post by Karen Tracey
On Sat, Jun 7, 2008 at 3:06 PM, Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.
Thoughts?
I'd trade your controversial part for an alternative: merge
mewforms-admin back to trunk now. It's been as 'usable' as old admin
for months. Sure, it's got a couple of dozen 'blocking' bugs in the
tracker but none of them are all that serious. Current admin, as you
note, also has some bugs. Trade the existing
known-never-going-to-be-fixed current admin bugs for a different set
of newforms-admin bugs and get on with fixing the second set already.
Once on trunk the community's interest will be higher so you'll get
better feedback on what is and is not really important to users, more
people who might help out with actual fixes, etc.
I think it's a shame newforms-admin wasn't done in a fashion similar
to newforms -- off in its own area of trunk for people to try out as
it developed, with the old stuff still available simultaneously so as
not to cause too much disruption. But that's water under the bridge,
unless it's an idea that might be used now. If the group really
thinks newforms-admin is not ready to take the place of current admin,
perhaps it could at least be made available on trunk alongside old
admin, much as both newforms and oldforms are available on trunk. I
know there are probably lots of irritating details on getting that to
work right, but maybe it's a possibility to think about? Really,
though, I think moving right on to newforms-admin by merging it to
trunk is what should be done.
Releasing a "1.0" without newforms-admin would, I think, be a huge
mistake. I thought the promise of "1.0" was stability -- no more
backwards-incompatible changes. Don't you completely renege on that
promise if you release a "1.0" with a major component that is going to
be replaced in a entirely non-backwards-compatible way some time down
the road?
Karen

+1


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthias Kestenholz]

Post by Karen Tracey
On Sat, Jun 7, 2008 at 3:06 PM, Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.
Thoughts?
I'd trade your controversial part for an alternative: merge
mewforms-admin back to trunk now. It's been as 'usable' as old admin
for months. Sure, it's got a couple of dozen 'blocking' bugs in the
tracker but none of them are all that serious. Current admin, as you
note, also has some bugs. Trade the existing
known-never-going-to-be-fixed current admin bugs for a different set
of newforms-admin bugs and get on with fixing the second set already.
Once on trunk the community's interest will be higher so you'll get
better feedback on what is and is not really important to users, more
people who might help out with actual fixes, etc.

+1

I know there is a commitment to keep trunk as stable as possible, but if
there is a push for moving forward quickly, this is the way to go. I'm
running newforms-admin for several public sites already, and have not
experienced a single problem which I'd remember now. Porting from the
current admin to nfa was very straightforward too.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Johannes Beigel]

Post by Karen Tracey
I'd trade your controversial part for an alternative: merge mewforms-
admin back to trunk now. It's been as 'usable' as old admin for
months. Sure, it's got a couple of dozen 'blocking' bugs in the
tracker but none of them are all that serious. Current admin, as
you note, also has some bugs. Trade the existing known-never-going-
to-be-fixed current admin bugs for a different set of newforms-admin
bugs and get on with fixing the second set already. Once on trunk
the community's interest will be higher so you'll get better
feedback on what is and is not really important to users, more
people who might help out with actual fixes, etc.

+1


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Alen Ribic]

Post by Karen Tracey
I'd trade your controversial part for an alternative: merge mewforms-
admin back to trunk now. It's been as 'usable' as old admin for
months. Sure, it's got a couple of dozen 'blocking' bugs in the
tracker but none of them are all that serious. Current admin, as
you note, also has some bugs. Trade the existing known-never-going-
to-be-fixed current admin bugs for a different set of newforms-admin
bugs and get on with fixing the second set already. Once on trunk
the community's interest will be higher so you'll get better
feedback on what is and is not really important to users, more
people who might help out with actual fixes, etc.

+1

We have a production-based web application running nsf for the past 4
months with no show-stoppers. (Small occasional bugs that already have
tickets, patches.)

-Alen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Mike Scott]

Post by Karen Tracey
I'd trade your controversial part for an alternative: merge mewforms-admin
back to trunk now. It's been as 'usable' as old admin for months. Sure,
it's got a couple of dozen 'blocking' bugs in the tracker but none of them
are all that serious. Current admin, as you note, also has some bugs.
Trade the existing known-never-going-to-be-fixed current admin bugs for a
different set of newforms-admin bugs and get on with fixing the second set
already. Once on trunk the community's interest will be higher so you'll
get better feedback on what is and is not really important to users, more
people who might help out with actual fixes, etc.

+1 from me, definately.
--
EB White - "Genius is more often found in a cracked pot than in a whole
one."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Tim Chase]

Post by Karen Tracey
I'd trade your controversial part for an alternative: merge mewforms-admin
back to trunk now. It's been as 'usable' as old admin for months. Sure,
it's got a couple of dozen 'blocking' bugs in the tracker but none of them
are all that serious. Current admin, as you note, also has some bugs.
Trade the existing known-never-going-to-be-fixed current admin bugs for a
different set of newforms-admin bugs and get on with fixing the second set
already. Once on trunk the community's interest will be higher so you'll
get better feedback on what is and is not really important to users, more
people who might help out with actual fixes, etc.

+1 as soon as it's deemed that NFA has surpassed oldforms -- as
measured by bug-free-ness, flexibility of the admin, and general
consensus of the core developers -- I think merging it into trunk
will

1) increase visibility by the less-adventurous (read "only as
adventurous as trunk, not a branch") developers

2) move a step towards Jacob's "let's get on a train" suggestion

3) appease the "we want a 1.0" crowd with notable progress
towards a 1.0


I'd also add that a public announcement like was done for QSRF
would help keep it well in the open, rather than a one-line "oh,
we merged NFA into trunk" added to the backwards-incompat page.
That way, like with QSRF, folks know there will be a shake-down
period where a higher volume of bugs will be found/filed and they
can prepare/test accordingly.


It might also help to have a clear catalog of "1.0 blocking bugs"
that would prevent a 1.0 release (there might be something in
Trac that gives this, but my poking didn't find it) so the "we
want a release" crowd has a tangible list they can be helping with :)

Just my $0.01

-tim




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Chad Maine]

+1. For my purposes, newforms-admin *is* trunk.

Post by Karen Tracey
On Sat, Jun 7, 2008 at 3:06 PM, Jacob Kaplan-Moss <

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.
Thoughts?

I'd trade your controversial part for an alternative: merge mewforms-admin
back to trunk now. It's been as 'usable' as old admin for months. Sure,
it's got a couple of dozen 'blocking' bugs in the tracker but none of them
are all that serious. Current admin, as you note, also has some bugs.
Trade the existing known-never-going-to-be-fixed current admin bugs for a
different set of newforms-admin bugs and get on with fixing the second set
already. Once on trunk the community's interest will be higher so you'll
get better feedback on what is and is not really important to users, more
people who might help out with actual fixes, etc.
I think it's a shame newforms-admin wasn't done in a fashion similar to
newforms -- off in its own area of trunk for people to try out as it
developed, with the old stuff still available simultaneously so as not to
cause too much disruption. But that's water under the bridge, unless it's
an idea that might be used now. If the group really thinks newforms-admin
is not ready to take the place of current admin, perhaps it could at least
be made available on trunk alongside old admin, much as both newforms and
oldforms are available on trunk. I know there are probably lots of
irritating details on getting that to work right, but maybe it's a
possibility to think about? Really, though, I think moving right on to
newforms-admin by merging it to trunk is what should be done.
Releasing a "1.0" without newforms-admin would, I think, be a huge
mistake. I thought the promise of "1.0" was stability -- no more
backwards-incompatible changes. Don't you completely renege on that promise
if you release a "1.0" with a major component that is going to be replaced
in a entirely non-backwards-compatible way some time down the road?
Karen

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[David Larlet]

Post by Karen Tracey
I'd trade your controversial part for an alternative: merge mewforms-
admin back to trunk now.

+1 if involved people in this branch agree (I hadn't found the time to
test it yet...).

Post by Karen Tracey
I think it's a shame newforms-admin wasn't done in a fashion similar
to newforms

Very good idea, the transition/merge will be easier if there is an
alternative like that.

David


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jacob Kaplan-Moss]

Wow, this thread keeps on keepin' on, eh?

So here's the deal. The core developers have always had a vague idea
about what would be in 1.0 and when it would be released, but it's
apparent we've not been formal enough about that plan. To wit, many
folks are complaining about a lack of a feature list for 1.0 even
though there's been one on the wiki for quite some time. Seems wikis
still don't inspire all that must trust -- sorry Jimmy.

I've been talking over the past few days with other core developers,
large-scale users of Django, and, well, anyone else I find on
#django-dev. I'm readying a proposal that I think should make most
people happy (or, at least, content). It's not quite done, and I'm
busy today, so plan to see it tomorrow.

Jacob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[testguy56]

Post by Jacob Kaplan-Moss
Wow, this thread keeps on keepin' on, eh?

Wow, starting a reply like that makes you sound like an elitist douche
bag.

Why not instead say, "There has been a few interesting proposals in
this thread," followed by your impending proposal announcement. You
run a high-profile, popular, and well-respected project, act like it.

Post by Jacob Kaplan-Moss
I've been talking over the past few days with other core developers,
large-scale users of Django, and, well, anyone else I find on
#django-dev. I'm readying a proposal that I think should make most
people happy (or, at least, content). It's not quite done, and I'm
busy today, so plan to see it tomorrow.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

Post by testguy56
Wow, starting a reply like that makes you sound like an elitist douche
bag.

I love the smell of troll in the morning, don't you?

[James Bennett]

(incidentally, for anyone who's joining in and wants to genuinely add
to the discussion: starting your reply by calling one of the
developers a douchebag causes me, at least, to stop listening and
simply assume you're a troll. The more you know...)

[testguy56]

Post by Jacob Kaplan-Moss
Wow, this thread keeps on keepin' on, eh?

Wow, starting a reply like that makes you sound like an elitist.

Why not instead say, "There has been a few interesting proposals in
this thread," followed by your impending proposal announcement. You
run a high-profile, popular, and well-respected project, act like it.

Post by Jacob Kaplan-Moss
I've been talking over the past few days with other core developers,
large-scale users of Django, and, well, anyone else I find on
#django-dev. I'm readying a proposal that I think should make most
people happy (or, at least, content). It's not quite done, and I'm
busy today, so plan to see it tomorrow.

There fixed that in deference to James Bennet -- who, incidentally,
genrerally comes off as only slightly more approachable than Jacob
Kaplan-Moss.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[aeh]

Get over it. No one writes a blog post as the first crack at a
problem. He's brought the stuff up before and did not meet with
satisfaction. For the record, I can't stand the passive-aggresiveness
of attacking someones honest attempt at criticism just because it
didn't enter the channel you designate.

Post by Jacob Kaplan-Moss
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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jacob Kaplan-Moss]

Hi all --

It's apparent from the recent blog and list activity that some members of the
Django community feel that we've screwed up in waiting so long to make another
release; some have started to despair that we'll ever ship 1.0. This uncertainty
has been confounded by our failure to be more transparent and open about the
roadmap for 1.0. Though the core developers all have a good picture of what
should be done before 1.0, I've done a lousy job communicating that and asking
for feedback. Further, it's clear that not having a definite timeline has really
pissed some people off.

This lapse of communication and lack of a timeline is primary *my* fault, and to
anyone annoyed, angered, or inconvenienced, and to the community in general,
I apologize.

I appreciate all the constructive criticism. Please, if you feel strongly about
this -- as I know many do -- come participate! I've just posted a draft 1.0
timeline.

Jacob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christian Joergensen]

(... 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)

Post by Jacob Kaplan-Moss
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.

I can see how one could percieve it as such, however there was no harm
intended with my blog post.

It was merely a case of trying to establish an argument as to why I
would like to see more frequent releases and documenting some of the
unfortunate side effects of the current model.

I myself have been very surprised as to how much fuzz this blog post has
generated. But on the other hand, I think the discussion is healthy for
the project. The users gets to express their views and hopefully the
Django team listens.

[...]

Post by Jacob Kaplan-Moss
* 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 an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.

That sounds like a great idea. As long as there is a schedule I think
most of "us" would be satisfied and shut up ;-)

That said; maybe now is the time for me to start poking around and see
if I can help out with anything other than the occasional patch a couple
of times a year.

Regards,
--
Christian Joergensen
http://www.technobabble.dk

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

Post by Rob Hudson
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 post.

It does indeed take time to roll a release. More importantly, issuing
a release means that we -- the Django team -- make a promise of
support for it, which is the important part and the part that
ultimately ends up eating much more time. It's also the part people
tend to forget about when they start asking why we don't just roll a
new release whenever they think we should.

We've stated in the past that the next official supported release of
Django will be 1.0. I think that's a good idea, and I personally think
we ought to stick to it; the things we've outlined for 1.0 are
significant enough that incrementally pushing releases before that
will do more harm (in terms of presenting a constantly-moving target
to the people who believe releases mean long-term stability) than
good.

And, really, that's the catch-22: if we released much more frequently
than we do now we'd likely get just as many complaints, only from a
different group of folks. As has been stated before, having people
upgrade from 0.96 to a 0.97 release based on current trunk would
subject those people to a fair number of required changes; having them
upgrade at each step along the way to 1.0 would impose that on them
repeatedly. That's not something I'd be comfortable with; I'd rather
try to minimize the number of releases which involve significant
end-user changes. The ideal is to just do it once, and then we're at
1.0 with a compatibility guarantee toward the future.

So personally, I think discussion of more aggressive release schedules
should happen once we're *at* 1.0, with a hard promise of stability.
Once we're there, more frequent releases (say, to add new features or
to expand django.contrib) make a whole lot more sense to me. But right
now as we're working through the changes necessary to reach 1.0, I
don't see much good in diverting that goal to produce interim packages
that will, in turn, increase our support workload.

[Patrick J. Anderson]

On Sat, Jun 7, 2008 at 11:48 AM, Rob Hudson

Post by Rob Hudson
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 post.

It does indeed take time to roll a release. More importantly, issuing a
release means that we -- the Django team -- make a promise of support
for it, which is the important part and the part that ultimately ends up
eating much more time. It's also the part people tend to forget about
when they start asking why we don't just roll a new release whenever
they think we should.
We've stated in the past that the next official supported release of
Django will be 1.0. I think that's a good idea, and I personally think
we ought to stick to it; the things we've outlined for 1.0 are
significant enough that incrementally pushing releases before that will
do more harm (in terms of presenting a constantly-moving target to the
people who believe releases mean long-term stability) than good.
And, really, that's the catch-22: if we released much more frequently
than we do now we'd likely get just as many complaints, only from a
different group of folks. As has been stated before, having people
upgrade from 0.96 to a 0.97 release based on current trunk would subject
those people to a fair number of required changes; having them upgrade
at each step along the way to 1.0 would impose that on them repeatedly.
That's not something I'd be comfortable with; I'd rather try to minimize
the number of releases which involve significant end-user changes. The
ideal is to just do it once, and then we're at 1.0 with a compatibility
guarantee toward the future.
So personally, I think discussion of more aggressive release schedules
should happen once we're *at* 1.0, with a hard promise of stability.
Once we're there, more frequent releases (say, to add new features or to
expand django.contrib) make a whole lot more sense to me. But right now
as we're working through the changes necessary to reach 1.0, I don't see
much good in diverting that goal to produce interim packages that will,
in turn, increase our support workload.

+1 on including NFA in 1.0 release (even if it has a few bugs). Stick to
what you presented in the list of 1.0 features and get it done. Imagine
people spending weeks porting their code to an interim release only to
have to go through another substantial code change just because of NFA.
I've been tracking trunk, so my changes won't be as huge, but for some
people, it will be massive, and I think they would all prefer to do it
once, no matter what they say now.

I think having a date everyone could look forward to would:

a) get everyone busy planning and preparing for it instead of venting
their frustrations.
b) help developers get it out the door.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[lgr888999]

About "release early, release often". If the core team would release
often the would spend more time merging bugfixes to several version
branches than actually doing the great stuff that they do to django.

Come on guys, we dont need releases. We are webdevelopers and the web
changes everyday.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/***@public.gmane.org
To unsubscribe from this group, send email to django-developers-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---