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@xxxxxxxxxx> Reply-To: transifex-devel@xxxxxxxxxxxxxxxx To: Transifex devel list <transifex-devel@xxxxxxxxxxxxxxxx> References: <6d4237680811051433n55ef48d7x668f19b0a9dfd9b4@xxxxxxxxxxxxxx> <6d4237680811051519g7d149ba3x616957ff1ea10f55@xxxxxxxxxxxxxx> 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@xxxxxxxxxx, 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@xxxxxxxxxx, 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@xxxxxxxxxx, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) --
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
