Django 1.4 Roadmap

[Srik]

Hello All,

I believe https://code.djangoproject.com/wiki/Version1.4Roadmap needs
update badly considering 1.3 was released 4 months ago and 1.4 Roadmap
was never updated.

There seems to be good amount of work going on as per commits to trunk
but what exactly are the goals of 1.4.

Will it be mainly bug fix (closing existing tickets) or can we expect
any new features (If so do we have a list elsewhere towards which
developers are working)?

Thanks
Srik

[rvanhoepen]

Can we make suggestions for new features to be added to the list?

[h3]

idk .. but I'll make one anyway.

I whish there was something like this for django: http://brainstorm.ubuntu.com/

Good news: the site's engine is Open Source
Bad news: it's ROR (http://bbyidx.com/)

Pretty decent alternative: http://www.google.com/moderator/

[Russell Keith-Magee]

On Sat, Aug 6, 2011 at 6:16 PM, Srik <srika...@gmail.com> wrote:
> Hello All,
>
> I believe https://code.djangoproject.com/wiki/Version1.4Roadmap needs
> update badly considering 1.3 was released 4 months ago and 1.4 Roadmap
> was never updated.

Agreed -- we haven't been very good with public plans for the 1.4
cycle. Internally, the core team had some discussions about some more
aggressive dates that would lead to faster cycles, but those dates
sailed past a long time ago.

At this point, I think we should be aiming at DjangoCon as a deadline
for the Alpha; with beta and final following at roughly 1 month
increments after that, which would produce a 1.4 release around the
end of November.

However, I hasten to add:

1) I haven't discussed these dates with the rest of the core team,

2) The real impediment to getting a release out the door is having
someone who has the spare time to manage the release process. That's
been me for the last two releases; I'm fairly certain I won't have the
spare cycles to make it three in a row.

> There seems to be good amount of work going on as per commits to trunk
> but what exactly are the goals of 1.4.
>
> Will it be mainly bug fix (closing existing tickets) or can we expect
> any new features (If so do we have a list elsewhere towards which
> developers are working)?

The feature list of 1.4 isn't likely to have a bunch of massive
features like 1.2; it's more likely to be like 1.3. That is, a couple
of big features, and a bunch of bugfixes. *Which* features is mostly
up to the community.

Essentially, the final feature list for 1.4 will be determined by the
list of RFC patches that are submitted. Some of those will be
contributed by core developers, some will come from the general
community. Bigger features will need some buy-in from a core developer
if they're going to get committed.

The lesson we've learned from the 1.1 and 1.2 cycles is that it
doesn't matter what someone wants to put on a feature list -- what
matters is actually producing the patch. So, it's better to set a date
and cut a release based on the features available at that date, rather
than wait for delivery of a feature that many people have expressed an
interest in, but nobody has worked on.

The moral of this story -- if there's a feature you want, *you* have
to make it happen, by writing patches, engaging the community, and
convincing a core developer that it's a must-have feature with
community support.

Yours,
Russ Magee %-)

[Russell Keith-Magee]

On Sun, Aug 7, 2011 at 12:40 PM, h3 <hain...@gmail.com> wrote:
> idk .. but I'll make one anyway.
>
> I whish there was something like this for django: http://brainstorm.ubuntu.com/
>
> Good news: the site's engine is Open Source
> Bad news:  it's ROR (http://bbyidx.com/)

The fact that it is based in RoR is irrelevant. It's a tool. If it's
the right tool for the job, We'd use it in a heartbeat. We're not
idealogs -- we're perfectionists with deadlines :-)

The *actual* bad news is that it's not connected to the Trac instance
that we use as a project management tool. I don't see that adding a
second issue tracking system in parallel to Trac would ultimately
improve anything.

This idea -- being able to +1 ideas and bugs -- is something that I
have said *many* times that I would *love* to see. However, I'm not a
Trac guru, and I don't have a whole lot of spare cycles to make it
happen.

I've been told that there are a bunch of 'voting' extensions available
for Trac; if this is the case, all we need is for someone with the
spare time to sort out the details.

Yours,
Russ Magee %-)

[Alex Gaynor]

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

"idealogs" I'm about 100% sure that's not the word you wanted, but it's awesome.

Alex

--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

[Russell Keith-Magee]

Oops -- ideolog. Or ideologue if you're spelling it right :-).

Neologistic homophones are AWESOME %-)

Russ %-)

[Florian Apolloner]

Hi,

On Monday, August 8, 2011 2:19:07 AM UTC+2, Russell Keith-Magee wrote:

someone who has the spare time to manage the release process. That's
been me for the last two releases; I'm fairly certain I won't have the
spare cycles to make it three in a row.

Is the release process documented somewhere and could someone from outside of the core team step in to help out here?

Cheers,
Florian