Hi,
after all I'm quite pleased with trac 0.12 and I'm absolutely on your
side when it comes to more frequent releases and your approach to
planning 0.13.
I have four concerns/issues that I'd like to voice (even if you dismiss
them in the end, I want to make sure that they don't go unnoticed):
1. Python 2.4 support. RHEL 5 ships 2.4 and is one of the major Linux
distributions out there (especially for shared hosting). Currently I
have problems installing 0.12 on some production servers as they are
still running RHEL 4 (Python 2.3!) which will change in 2012.
RHEL 5 will be supported until 2014 and I'd like to make a point of
supporting it for a couple of years more.
2. Completely denormalized databases: I don't know if
http://trac.edgewall.org/wiki/GenericTrac is a precondition to multi-
project support and the current state but I have to say that I
really feel that SQLAlchemy could help with a couple of issues and I
think that going completely denormalized contradicts my gut feel of
a good architecture.
3. Long-term support for certain releases.
Currently Fedora EPEL 4/5 (RHEL 5) are shipping trac 0.10, Fedora
EPEL 6 (RHEL 6) will ship 0.11 because of Genshi 0.5. There is
interest from the Fedora/Red Hat side to fix security issues in
these versions. Can you think of a process of doing so?
My main point is that I want to avoid having a couple of custom
patches that every distribution need to maintain themself. I'd like
to gather at least all produced patches in one place (even if they
don't fix all issues). From experience the best place for this is
upstream svn.
4. Evolution of the ticket system.
Of course I'm biased here but I really like to see some evolution in
trac's ticketing capabilities. So far I did not attempt any action
to improve the situation as I was under the impression that my
patches would be rejected anyway. Major topics for me:
1. Ticket linking (think 'duplicate of'), possible with semantics
defined by additional plugins.
2. Different fields by type (e.g. an enhancement has no 'version'
field. Further steps could be also different field contents by
condition 'X' (e.g. 'Project A' has different components than
'Project B')
3. Fine-grained security: Enable policies to hide certain elements
(e.g. some milestone values) for some users (e.g. an anonymous
user can not plan something for 'next-minor-0.12.x').
So my main question here is if you would include patches that enable
some of these features (even if it is just the infrastructure so
that a plugin can do this without horrible monkey-patching)?
fs
PS: @all - please minimize quotes in your replies.
--
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.
