On Jun 27, 2010, at 6:02 AM, Christian Boos wrote:
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.
+1 on >=2.5.
Also something that was brought up before but not really discussed,
Genshi. Do we want to continue trying to improve it or do we undertake
another template swap? This might even be too big a thing for 0.13,
but if 0.14 is to follow soon after we should probably work out an
official stance.
--Noah
--
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.
