On 29/10/12 07:57, Peter Koželj wrote:
On Sat, Oct 27, 2012 at 11:11 AM, Joe Dreimann <
[email protected]> wrote:
On 27 Oct 2012, at 04:29, Peter Koželj <[email protected]> wrote:
[...] as a user I surely don't
need separate email for each affected ticket, just the one saying that
product or milestone or whatever has changed would be enough.
Peter
Fully agree.
- Joe
Ok, if I try to recap all this and try to think about what it all means:
We agree that data model as is needs fixing (it is not enterprise or
distributed environments friendly). Some of the fixes are local (like
multiproduct plugin) for other it seems that we should just do them through
BH and offer the solution to Trac. But what are the implications?
1. We would deviate from standard Trac quite a bit with a risk that our
changes are accepted with a big delays or even rejected. Merging in new
Trac versions could become a nightmare. Would we be willing to stay on Trac
1.0 for ever? And we would have to go from "...on the shoulders of Trac..."
to "... not compatible with Trac...".
2. With the lack of data abstraction or data access constraints on a plugin
level, plugins depend on this same database model. We will lose
compatibility with most of the plugins that relay on the Trac database
schema. And if we would insist on using some of the existing plugins for BH
functionality we would be forced to fork them (see next point).
3. Adding data consistency on database level will break current plugin
model. Data imports and schema upgrades become nontrivial and would require
special inter plugin protocol to synchronise all that. Asking plugin
authors to support two different data models and two different plugin
models seems a bit much and would probably mean two different plugins (trac
and BH) for the same functionality. So do we want entreprise DBA support or
plugin authors support?
Peter
I don't want to be moving away from Trac as I still think that both
communities will be able to benefit from each other. We can probably
expect the schema and APIs for Trac to evolve over time and so Trac
presumably has to manage the same risk of breaking compatibility and
pulling the trac-hack community with them.
It would certainly be difficult for plugin authors to support multiple
plugin models. It is not unusual at this point to see plugins supporting
older versions of Trac so for those it might be a question of how much
can it hurt to support one more but, with no firm guarantees of our
system being fixed, the effort to potentially support multiple versions
of Bloodhound as well would probably put that in doubt too. To make that
work we would probably need to make sure that changes are generally
transparent and always easy to convert as well as supplying a lot of
support for the process.
Going back to the problem with multiproduct, I'm happy to see us
swapping to using the immutable product prefix. I am not yet convinced
of the argument of providing an extra field for the convenience of
allowing us to easily make the prefix mutable. Withholding the ability
to change the prefix will be simplifying for the users of the system so
that they do not have to get used to referring to tickets through a new
prefix on the whim of another user. While we could provide the ability
for the old prefix to continue to be usable for identifying the
appropriate resource under the new prefix, the potential confusion in
discussions of tickets just seems unwarranted. The workaround exists of
creating a new product and moving the tickets into it.
As for the question of notifications, I agree that we don't want
multiple emails associated with a a change of product but I think it
would be nice for resources that were associated at the time of the
change to be able to report that the event has happened. On the other
hand, the activity feed should really only show one event at any given
scope. I am not convinced that that the bulk modify apparatus is the
correct approach for this in the long term.
Cheers,
Gary
