On Mon, Jun 9, 2008 at 3:57 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
> 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)
> 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).
> 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).
> 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.
--
"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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
