On 6/27/2010 11:03 PM, Felix Schwarz wrote:
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.
We certainly don't want to make things unnecessarily difficult for our
users, but not at the cost of freezing the set of language features we
can use or by targeting systematically the lowest common denominator.
For that reason, I think it's not unreasonable to require a Python
version which by the time Trac 0.13 becomes available, will be more than
4 years old.
Out of the many features 2.5 will bring, I already cited the "with"
keyword which we badly need for our automatic transaction management,
but other things (ternary op, unified try/except/finally) will
contribute to make the code more robust and cleaner.
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.
I'm not sure if I understand what you mean by "denormalized database".
Are you refering to the duplication of data in ticket related tables, as
discussed in #1890, or to the fact we don't use yet surrogate
keys except for the new repository table? Or the fact that relationships
between tables rely on "implicit" foreign keys (e.g. ticket -> milestone)?
The ideas exposed in GenericTrac will certainly help in those aspects,
but in general this is somehow orthogonal to the other enhancements and
multiproject support. Nevertheless, at the occasion of introducing new
tables (e.g. project), we'll certainly go with something in this
direction, a bit like we did with the repository table.
On the topic of SQLAlchemy, I'm personally very reluctant to consider
adding such an important 3rd party dependency which will require some
pervasive rewrites, when the benefits are not clearly demonstrated. I'm
not asking for the list of SQLAlchemy features here, which I'm aware of,
I'd rather see some answers to my recurring questions on this topic
which were never answered by SQLA proponents, see e.g.
http://trac.edgewall.org/wiki/TracSprint?version=16#SQLAlchemy or ...
the numerous threads on this topic on Trac-dev.
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.
I can't say for Fedora people, as they never contacted us directly
AFAICT. We once had a contact from an Ubuntu developer which was
basically going like this: "Hi, would you mind sending me the patches
for those CVEs? (list of CVEs)". All issues that were long time fixed by
us upstream, but that they didn't have in their shipped versions (0.9.3
+ patches, 0.10.4 + patches, 0.11 + patches). I personally have doubts
concerning the supposed greater stability of such patched releases,
compared to one of our regularly tested 0.11.x bugfix release. It's
however true that if we add at the same time a lot of minor
enhancements, I understand they can be reluctant to upgrade the package
wholesale as part of a security update.
So this is another reason on insisting to have only the important bug
fixes in our stable branches. And this is essentially the way I see for
improving the situation for every party, in the future. We have to get
the package maintainers to realize that our 0.12.x releases will be bug
fixes / security releases and that when aiming for greater stability,
the best solution for them is to just pick the most recent 0.12.x
version. Or put it differently, if they'd like to cherry pick the
important fixes by themselves, they'll end up with "something like"
0.12.x, so they could as well use the official and recommended version.
Ideally the package maintainers should also be playing directly a role
in the maintenance of a stable branch, for example by monitoring the
activity on 0.12.1 and next-minor-0.12.x tickets and providing feedback.
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)?
We're willing to see improvements in the ticket system, yes, especially
based on concrete contributions.
For example, Steffen Hoffmann has started to work on support for custom
date and time field, he has a proposal and some code already, see
http://trac.edgewall.org/wiki/TracTicketsCustomTimeFields. I can't make
any promise about "when" integrating this work will happen, but it will
certainly be possible during early 0.13dev.
So for the 3 points above, it can make sense to start your own
experimental branches, document how you see those features could be
implemented. In particular, explaining in some details how this would
solve or mesh with other issues, e.g. #1395 for point 1, #2464 for point
2,
http://trac.edgewall.org/wiki/TracDev/Proposals/EvenFinerGrainedPermissions
for point 3.
Note also that for your point 2, some different approaches can be
envisioned.
First, in the scope of MultiProject, it's quite clear that /in general/,
components shouldn't be shared. Components are currently enums rather
than resources on their own, but that's an implementation detail, be it
resources or enums, we need a way to specify that a component is
specific to a project. If that project is the root project or a parent
project common to A and B, then the component might be shared and used
in both A and B.
For ticket types, we can imagine having actual "types" with common base
behavior, but specialization possible. For example, the list of default
fields could differ. Note this is something that fits well in the
GenericTrac approach with the lightweight schema.
-- 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.
