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
