[Fwd: [tx-devel] Roadmap thoughts]

Thu Nov 6 01:42:10 UTC 2008

FYI: Roadmap for Transifex's port to DJango and how long we have with
the TurboGears version before we have to start thinking about making the
new version work.

-Toshio

-------- Original Message --------
Subject: [tx-devel] Roadmap thoughts
Date: Thu, 6 Nov 2008 01:26:06 +0200
From: Dimitris Glezos <dimitris at glezos.com>
Reply-To: transifex-devel at googlegroups.com
To: Transifex devel list <transifex-devel at googlegroups.com>
References:
<6d4237680811051433n55ef48d7x668f19b0a9dfd9b4 at mail.gmail.com>
<6d4237680811051519g7d149ba3x616957ff1ea10f55 at mail.gmail.com>

I'd like to share some thoughts on having a roadmap for the upcoming
releases and next months. Get everyone is on the same page and
make sure we have a consensus on our actions.

Development on mainline is more or less frozen since we've been
hammering the Django branch to shape, together with Diego.

I'd like us to release a 0.4 major release from the TurboGears branch,
based on the current tip of the mainline branch. This release can be
maintained for bugfixes in the form of 0.4.x for a few months, in case
there are deployments of it. I've documented the current features:

 http://docs.transifex.org/releases/0.4.html

The Django branch, once it's mature enough release can become 0.5.
This release will include at least everything the TG branch has and
many more:

 http://docs.transifex.org/releases/0.5.html

What does this mean to projects like Fedora and GNOME? I believe
Fedora can install 0.4 right away, and take its time to deploy 0.5,
since it's the first Django app on its Infrastructure. With GNOME
we have enough time until the feature freeze to include the
features we need (collections, releases, etc).

With Django's pluggable architecture, it's much easier to start
experimenting with these, without affecting the core functionality.

One open issue is Christos' work on the submissions branch.
I've ported this work on the VCS layer almost without any changes
in the Django branch. It's our solid base for VCS support for all
future releases. The Q is whether it's worth merging it into 0.4 as
well, or if it's more efficient if we cherry-picked any bugfixes from
that branch into mainline. I'm wondering whether we're better off
keeping 0.4 stable and simple, given the fact that it will only exist
for a few months.

Roadmap to 0.5
--------------

Since we have a lot of work until reaching stability and the feature
set of 0.4, we're splitting up the work in minor 0.5 releases or
milestones, in the form of 0.5m1, etc. Aiming for a few of them:

- 0.5-m1 (Finished): Bare minimum

  Code refactoring, Units, Project registration, Basic i18n, VCS layer
  complete, initial data there

- 0.5-m2 (Finished): Announcment of the Django branch to the
  developers and core testers

  OpenID, Notifications, Deployment, non-master branches work,
  statistics, languages

- 0.5-m3 (Half-finished): Announcement of Django branch to the general
public

  OK: login_required for editing , use dynamic site_name, download POs
  Working on them: Catch most exceptions, all VCS work on tx.net

- 0.5-m4: Ready for testing from projects

  Project Collections, User profiles, Better docs in the UI, Logging

- 0.5-m5: File Submissions

- 0.5-pre: Everything needing completion before 0.5 Gold

  Everything from TG branch works, documentation completion, wsgi
  deployment, admin panel refinements

- 0.5 Gold

Development from here will continue as usual: The goal is to
have minor releases which will not break the ABI. In any way, we'll
use django-evolution to allow schema evolution for model changes. A
few draft ideas for minor releases:

- 0.5.1: Comments, Sitemap, Invitations. Maybe: Msgmerged i18n support.

- 0.5.2: More admin features, Basic CLI, AJAX. Work for better support
  for GNOME and Fedora.

- 0.5.3: Full CLI+auth, fine-grained permissions, complex
  notifications, workflow, svn+https support

- ...

- 0.6: First release with major backwards-incompatible changes, like
  File monitoring, Project owners, etc.

Important dates
---------------

Given the fact that there are some big gaps in development time for a
few of us, it's not easy to put some close hard dates on the above.
But we're aiming in something like the following:

- 2008-11-06: 0.4 released, branch off.
- 2008-11-08: Finalize 0.5 feature set
- 2008-11-15: 0.5-alpha (0.5-m3)
- 2008-12-13: 0.5-beta (0.5-m5)
- 2008-12-16: Feature Freeze (0.5-pre)
- 2008-12-23: 0.5-rc1
- 2008-12-29: 0.5-rc2
- 2008-01-04: 0.5 final

Thoughts, ideas, flames?

-δ

--
Dimitris Glezos
Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--

--
Dimitris Glezos
Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--

-- 
Dimitris Glezos
Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20081105/24043a72/attachment.bin 