Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gary.martin@wandisco.com
 designates 209.85.214.47 as permitted sender)
Message-ID: <508E57C9.5000809@wandisco.com>
Date: Mon, 29 Oct 2012 10:17:45 +0000
From: Gary Martin <gary.martin@wandisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: bloodhound-dev@incubator.apache.org
Subject: Re: Datamodel and data consistency
References: 
 <CAKE9Bs-8vonCB7idTJGLAYd=1MmBYxQwRVcYkeW3KSLWg7-dZA@mail.gmail.com>
 <CAPt9QwT+kmebqzhw-kxZtbdX5nwBRTUtQOpqOro6gGOSPCnS9A@mail.gmail.com>
 <CAKE9Bs-_49FFBn7nm9uNXSNYGFfRJ-QsTKgxadL+-CaNTpBmaw@mail.gmail.com>
 <CAGMZAuMH_bjnUJf-Y3xjCmTkk7OT0VFdcfmvgcFP6ncSL706Lg@mail.gmail.com>
 <508A4CAB.3070106@digiverse.si>
 <CAPt9QwS6E7tVEHHQZ8PZy37rRs77=LiL-RbjFJ5MhTQMBTU2Ew@mail.gmail.com>
 <CAGMZAuO6RVoTKk7RyqJC+n9fNmHNJ18XeV5_U9OMX2P+NX+4yw@mail.gmail.com>
 <CAKE9Bs_Dw9Y=sF_41x=9zHFortiUcBqwu8qBNiZZYRfA4zeP1A@mail.gmail.com>
 <E26FC9A5-6750-4552-9332-05C8D03D1A1A@wandisco.com>
 <CAKE9Bs-3682OUtbvhfke_tXZVuTt4_ZVf2QdC6b82QCkbLr8=A@mail.gmail.com>
In-Reply-To: 
 <CAKE9Bs-3682OUtbvhfke_tXZVuTt4_ZVf2QdC6b82QCkbLr8=A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 29/10/12 07:57, Peter Koželj wrote:
> On Sat, Oct 27, 2012 at 11:11 AM, Joe Dreimann <
> joachim.dreimann@wandisco.com> wrote:
>
>> On 27 Oct 2012, at 04:29, Peter Koželj <peter@digiverse.si> 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