Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gary.martin@wandisco.com
 designates 209.85.214.47 as permitted sender)
Message-ID: <50A38237.1070009@wandisco.com>
Date: Wed, 14 Nov 2012 11:36:23 +0000
From: Gary Martin <gary.martin@wandisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: bloodhound-dev@incubator.apache.org
Subject: Re: Multi product enhancements
References: <509A10FF.7020809@digiverse.si> <509A2A08.3070409@wandisco.com>
 <CAEZ-ge5Uh_zCF-e8anh8H1kr-1bCdJcyKyVgksqAfZYCrAE0hw@mail.gmail.com>
 <50A26830.9020700@digiverse.si>
 <CAGMZAuN99CWNSdMvp95DqX_5oz3y39hph=LwwnMyd_W-_f+-gw@mail.gmail.com>
In-Reply-To: 
 <CAGMZAuN99CWNSdMvp95DqX_5oz3y39hph=LwwnMyd_W-_f+-gw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------090107040809060907060908"

--------------090107040809060907060908
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 14/11/12 08:38, Olemis Lang wrote:
> On 11/13/12, Jure Zitnik <jure@digiverse.si> wrote:
>> On 11/7/12 9:58 PM, Gary Martin wrote:
>>> On 7 November 2012 09:29, Branko Čibej <brane@wandisco.com> wrote:
>>>> On 07.11.2012 08:42, Jure Zitnik wrote:
> [...]
>> I did a bit of code digging to get an idea how the product ticket
>> namespace could be implemented and I came up with a problem described
>> below ...
>>
>> In my opinion the most obvious way to keep the product ticket namespace
>> would be to introduce a new database table that would link the product
>> to the ticket by adding additional info,
> If you need a new product-specific ticket number sequence (which I
> don't think is really needed , at least for the moment) maybe that's
> ok *IF* other mechanism like custom ticket fields is not enough.
>
>> such as ticket sequence in that
>> namespace.
> btw , what's the decision on having consecutive ticket sequence
> per-product ? Is it a design goal ? That will only make things harder
> at the beginning while we try to sort out more important puzzles . Can
> we make it clear whether consecutive ticket sequence per-product will
> be included or not ?
>
> fwiw ... I'm -1 about adding it soon ... maybe later

At the moment I am of the opinion that it is something we need to sort 
out relatively quickly so that fewer people feel any pain of a transition.

A single ticket number range in a system is the easy choice but leaves 
us with a number of problems to consider when we look to import tickets. 
For example, if an admin user wants to combine two existing trac 
environments then the #ticketnumber links in comments and wiki pages 
will fail. OK, so let's say that we could consider carefully adjusting 
those ticket numbers to point to the new ticket numbers.. would we also 
be looking at updating all the version control commit messages that 
refer to tickets? This seems a bit much.

If instead we have continuous ticket numbering within a product, the 
problem described above is potentially eased as we could consider 
references to tickets from within a product to be referring to tickets 
within the product. So within the bh product, #1234 will always refer to 
a bh product ticket. This should work well for references *to* tickets 
that used to be in the product as we can maintain old ticket links in 
such a way that they redirect to the new ticket reference. References 
*from* a moved ticket are a little more problematic - I tentatively 
suggest that these would have to be detected and adjusted to specify the 
old prefix at move time.

It would seem that version control will also have to be considered to be 
linked to a specific product in order to make existing links work for 
legacy ticket numbers.

As for the transition from a bloodhound with non-consecutive ticket 
numbers within a product to this system, I suppose we might have to 
allow for holes in the ticket ranges. Of course, this supposes that it 
is something that people are already using.

By the way, something else that might be up for debate is the forms that 
we want to allow prefixes to be specified. Reusing InterTrac links would 
a natural fit as this would support bringing two environments together 
that used to be linked with such links. For tickets, that would give us 
links like:

  * prefix:ticket:1234
  * prefix:#1234
  * #prefix1234

and I believe that these are case-insensitive. I think it may also be 
worth considering adding the JIRA style BH-1234 at some point as well.

>> But as we want to perform the database inserts prior to sending out
>> email notifications (let's say we want to include newly generated URLs
>> from the product ticket namespace in the notification emails) we can't
>> really simply call the original/trac methods. So, to accomplish this
>> (single transaction for both inserts, product ticket namespace URLs in
>> notifications), we would need to literally copy parts of the trac code
>> to the overriden methods and add/modify the code to handle product
>> ticket namespace and notifications ...
>>

An alternative might be to store details of the ticket sequences within 
a product namespace on the ticket itself. This should allow us to make 
use of Trac's standard update mechanisms and so keep these changes in a 
single transaction.

> The solution for adjustment of product resource URLs should happen
> transparently . That's what «product environments» [1]_ are for . I'll
> explain how they'd work soon once I continue writing BEP 3 . Feel free
> to drop some ideas in there too ;)
>
> [...]
>> Patching trac would
>> possibly solve this but if we want to keep the plugin functionality
>> separate from trac that's really not the proper way of doing things.
> Please let's try to modify (copy , duplicate ...) code rarely , and
> only if there's a very good reason to do so . Changing things in there
> may break many other parts of the system and external plugins .
>
>> Using the trac code copy in overridden methods is also suboptimal. I
>> noticed though that the bloodhound theme (quick ticket create) sort of
>> uses this second approach.
>>
> Kind of ... but create_ticket has been copied from XmlRpcPlugin , so
> it's a well-known , reliable (and tested ;) implementation .
>
>> I'm bringing this up partly because I have a strong suspicion that we'll
>> come across the same issues if/when we start thinking of implementing
>> per product wiki, components, milestones, versions, etc.
>>
> Yes . So the solution should not be to start patching Trac all over
> and (it does not stop there) merging subsequent changes with time .
>
> .. [1] Some ideas on Multiproduct architecture
>          (https://issues.apache.org/bloodhound/attachment/wiki/Proposals/BEP-0003/Multiproduct.png)
>

Cheers,
     Gary

--------------090107040809060907060908--