Hello,
As you must have noticed, 0.12 is now behind us. It's the conclusion of
the past two years of tremendous activity, with my fellow Trac'er Remy
gradually taking "control" over the whole Trac code base (139 tickets
vs. "only" 88 tickets for me, congrats rblank ;-) ). We had lots of
valuable contributions from the rest of Trac community. There are 28
people who "own" one ticket, as they have proposed a patch that got
integrated and 13 more who got attributed at least two tickets: Erik,
Eli, Felix, Jan, John, Jun, Jeroen, Mark, Mikael, Oren, Ryan, Anatoly,
and Vaclav. We also received lots of help from our translators (I still
owe a virtual beer to Mikael for helping me to fix #8588, and another to
Jun for finally adding i18n support to our Javascript code), and most of
the regular translators are also now maintaining their respective
translations on their own, with commit privilege (15^H^H18 people! 3
more since I started to draft this mail ;-) ). Special thanks also go to
Christopher, Jonas, Jeroen and Pedro, whose contributions to Babel and
Genshi made the i18n work on Trac possible in the first place.
That was a good and productive time, I enjoyed it a lot; so, now what's
next on our plate? ;-)
First and foremost, we will try to build on the increased activity we've
seen these past months, and we'll do our best to motivate our
contributors. Several people have started to contribute high quality
patches already (Mikael, Jun and Itamar) and we sincerely hope they keep
on doing this, eventually joining us as part of the "core" team. We will
try to improve our development workflow in several ways:
- shorter development cycles so that the new big features reach our
users earlier;
- improved SCM tools;
- more clarity for the features we want and don't want, improved
ticket triage rules and well defined "conceptual" milestones.
About the tools, we're going to keep Subversion for now, but we'll also
start to actively support git and hg mirrors, as this will make it
easier for everyone to share topic branches, create patches and keep
them in sync with "upstream" changes. Instead of having to do their own
mirroring (which eventually will end up putting a lot of demand on our
svn server), we'll propose ready to use git and hg mirrors. We can
already announce a Git mirror on Github
(http://github.com/edgewall/trac), and a Mercurial mirror at
bitbucket.org will be usable soon (wait until we announce it).
Then, before even talking about 0.13, let's mention what we plan to do
for the 0.12.x maintenance branch. First, we will drastically limit
ourselves to not add new features there, only doing the important bug
fixes. This is mainly because experience has proven that otherwise,
there's less incentive to really focus on the next major release. The
second point is that we will try to cut out regular releases, something
like every two months. We need to have people regularly testing and
using the tip of the stable branch in production, so that we can be
confident to package the 0.12-stable branch anytime we want.
We also have a last 0.11 release to make (0.11.7.1), after which the
0.11-stable branch will be closed.
Releasing 0.12.1 doesn't seem to be very urgent, as 0.12 proves to be
quite solid. We have #9439, which is a bug happening if the install
sequence is Trac first, followed by Babel second, something we obviously
didn't test much ;-) The workaround is simple (remove the Trac .egg,
re-install), so fixing this is also not so pressing.
We need to spend a bit of time doing some ticket triage:
- most urgent is to move enhancements requests out of 0.12.1/ 0.12.x;
(done yesterday)
- keep only what really needs to be kept on the radar in
"next-major-0.1", as guidelines of what we want to achieve in the future
versions;
- move to "unscheduled" what we're not convinced of, close as wontfix
what we don't want to have;
The "triage", "next-major-0.1X" and "unscheduled" milestones all have
Maintenainer Notes which explain how the triaging should be done. We
still have 468 tickets to triage, a lot but doable. This breaks down
into 30 unseen (report:20), 198 in "triaging" and 240 tickets that need
to be re-validated for next-major-0.1X (the
query:milestone=next-major-0.1X&changetime=..05/01/10 ones).
Like already stated in a previous mail, we're going to be quite
conservative about what we assign to 0.13, basically only the things we
really want to have done *and* we're reasonably sure we can achieve. The
idea is really to keep the current major milestone as a "working set",
and have the "next-major-0.1X" milestone as a kind of staging pool where
a feature can be discussed, accumulate ideas and patches and when mature
enough, be brought to 0.13 (or whichever milestone is "current", as this
procedure will probably stay for 0.14, 0.15 etc.). There, the priority
serves as a rough indicator of when we think this will move from the
pool to a concrete milestone, and the severity gives an indication of
the importance of the ticket. This means for example that the low prio /
critical severity tickets are important long term goals.
Now let me get to the content of 0.13, as we see it...
We have some very nasty bugs to fix, namely #9111 which is symptomatic
of a weakness in the database connection cache. You can experience this
nearly daily with t.e.o freezing for a while, sometimes even until we
manually restart the lighty server. Fixing this is high prio, but due to
the relatively obscure nature of the bug, this could still take some
more months...
One of the major task I'd like to achieve for 0.13 is an overhaul of the
wiki engine. Over the years, I've become quite familiar over the
strengths and weaknesses of our "wiki formatter", and I think I can try
(again) a rewrite. The main idea is to build some kind of parse tree
(WikiDom) which can later be formatted or analyzed in various ways. See
http://trac.edgewall.org/wiki/WikiEngine for an overview of the ideas
and tickets (no code yet).
Some related enhancements are improvements to the Wiki user interface
itself, most prominently the "Section Editing" feature (see
TracDev/Proposals/AdvancedWikiOperations for an overview).
The next major topic for 0.13 will be the introduction of Multiple
Project Support. This is not only something our users badly need, I need
it badly myself as well... As for multiple repository support (which was
a prerequisite for the general case of multiple project support), we'll
introduce this feature in a way that will be transparent to the people
not needing it. This means that a single project Trac instance will
continue to work as before, maybe with the exception of a new project
summary module (#1!). The support for multiple projects should be
flexible enough so that it accommodates all kinds of situations: several
completely separate projects, a master project and sub-projects, a
complex tree of projects, with shared wikis or not, which shared or
separate milestones, etc. There's still a lot to do to even figure out
what we should do, but we've been postponing that for too long already
and it's about time we start working on a solution. See
http://trac.edgewall.org/wiki/MultipleProjectSupport (also not much to
see yet).
The last main topic is about some general improvements to the repository
browser and the support for distributed version control systems. As
we're going to use more and more hg and git, the support for these
systems in Trac should also gradually improve (for example a better
support for branch history, #1492).
Now this may already sound "too much" for a single release, especially
one for which we want to go back to a shorter release cycle (months
instead of years ;-) ). Well, we'll see. And if not everything is ready
by the time we want to release 0.13 (end of 2010), these features will
be in 0.14, 0.15 ... much better to have *something* already sooner that
to have to wait again for another 2 years for getting all the major
features at once.
The corollary to a faster release cycle is that we need to improve the
way we interact with the community of plugin developers. If we have more
frequent major releases, this means there are also more occasions to
break the plugins. Of course, we can try to minimize the backward
incompatible changes (we already do), but that's not always possible. So
we need to better communicate about the changes we make. We already
maintain the http://trac.edgewall.org/wiki/TracDev/ApiChanges pages, but
we'll need to improve upon that. One way will be to add an "api-change"
wiki custom field to tickets, where we'll summarize the changes
introduced at the occasion of this ticket that developers need to be
aware of. Note that in the same spirit, we'll have admin-change and
user-change fields. The other way will be to have at last an API guide
(make apidoc - no don't try it yet ;-) ). We'll also try to make some
early alpha releases, as a way to promote testing and getting feedback
on known stable points of the trunk version, but with no commitment on
the stability of the API or on the feature completeness of such
versions. Those release points will however make it easier to talk about
changes in the API /during/ the development period (as in "we changed
that since alpha2"). Lastly, plugin developers will be encouraged to
have a development process with branches matching the ones of Trac.
Trying to support multiple major versions of Trac in one branch of the
plugin is already difficult and prone to introduce bugs in the plugin
even when used together with an older version of Trac (e.g. breaking a
0.11 version when introducing support for 0.12). It can only get worse
if we ship major releases more often (say 0.13-0.16 in the same time
span that saw 0.11 and 0.12). With all the facilities that modern SCM
tools provide to port fixes made in the oldest supported branch by
cascading it to the newer branches, this shouldn't be that problematic.
Also, with rumors of TracHacks migrating to 0.12, the support of
svn:mergeinfo in Trac via the eligible links could prove useful (if
performance is adequate... we'll see).
Speaking about backward incompatible change, we'd like to move to Python
2.5 as the minimum required version of Python, mainly for being able to
use the 'with' keyword. Most Linux distributions ship Python 2.6 since
some time already and Python 2.7 final will be out soon, so we're in
line with our usual practice of supporting the last 3 stable versions of
Python.
Now I realize this mail is perhaps a bit long, so thanks a lot for
having read that far ;-)
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
