Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4F0DA4E1.8070105@wandisco.com>
Date: Wed, 11 Jan 2012 15:04:01 +0000
From: Gary <gary.martin@wandisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: bloodhound-dev@incubator.apache.org
Subject: Re: [Trac-dev] Bloodhound / Trac Approach
References: 
 <CAGMZAuPFVp84AossEOva_-GtrD2q5yBqZ48hbX9gGFgsOpKhyA@mail.gmail.com>
 <4F07380E.7060505@wandisco.com>
 <CAJjMeYMQTdhLaDwv8YMP43nu0g3MrEfKpaWYGCZd_FXFZT7L7Q@mail.gmail.com>
 <4F08E39E.3060001@wandisco.com>
 <CAGMZAuN4psWDNKR57V2cqzyWzmu1qBq_k9s1=n+wuSJ2-xqgWw@mail.gmail.com>
 <4F0C3990.4020906@wandisco.com>
 <CAGMZAuO4hnnPn10fQFgmEtHD6btGRXgU2+kohvtEYv=hz6Ge4A@mail.gmail.com>
In-Reply-To: 
 <CAGMZAuO4hnnPn10fQFgmEtHD6btGRXgU2+kohvtEYv=hz6Ge4A@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------070908020600040808060002"

--------------070908020600040808060002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 01/10/2012 04:06 PM, Olemis Lang wrote:
>
>> and we might be able to avoid changing existing tables by also providing a
>> table that maps resources to their project.
>
>
> exactly !
> Even if I didn't mention this before it seems we are in sync (as that's a
> bit straightforward reasoning ;)
> In fact I was thinking of considering projects as yet another Trac resource
> and therefore try to implement such mapping as similar to TracRelations
> spec [1]_ as possible / needed .
I am not sure of how much work it would be to go with that. 
TracRelations is not claimed to be a complete specification and so it 
might be better to avoid until it is implemented in Trac. It is a 
similar feeling that I get with talk of GenericTrac. I don't 
particularly like having to specify that we should write our solution 
with the expectation of refactoring but, then again, a move to 
GenericTrac would result in a refactor of everything else so I don't see 
quite so much harm.
>
>> Or we could just add the extra project field to the appropriate tables.
>> There is something appealing to me about the latter no-nonsense approach :)
>>
>>
> What'd be the pros&  cons of (1 - project to resource mapping table) vs (2
> - extra project field) ?
> IMO #1 is in sound with the more generic TracRelations proposal (as far as
> DB is concerned , project-specific behavior is another $0.02 ;) whereas #2
> breaks the more generic resource relations framework @ the DB level .
Well, in a sense, anything that should belong to a project does belong 
to a project, even if it is the null project (or whatever). That 
suggests to me that it is a property of the object rather than a 
mapping. However, the resource table would allow for a resource 
belonging to multiple projects. I am not sure that is appropriate yet. 
On the other hand, it would allow for independent database versioning 
and upgrades.
> ... question may also be reformulated this way : Considering TracRelations
> is out there , what makes projects so special so as to make an exception
> with them at the DB-level ?
>
> Either way I was thinking of providing projects with at least the following
>> details
>>
>>   * name
>>   * short_name (unique and fixed)
>>   * description
>>
>> where the short_name acts as a label in any referencing between projects.
>>
>>
> +1
> ... once I submitted project labels proposal [2]_ to trac-dev it was noted
> (with strong arguments IMO) that resource history may be important to be
> tracked as well . For project labels it makes sense . Maybe we should
> consider whether history meta-data might be appropriate for projects&  what
> events exactly will be tracked during project lifetime .
I thought that the arguments around that were about changes in name. I 
should probably look closer at that but the reason that I want 
short_name to be fixed is to reduce ambiguity. That said, a history does 
not seem unreasonable.
> Isn't the Trac-ky thingy just lovely ?
> I hope we all can make it better ...
> :)
>
> Personally I would also like to see independent ticket numbering per
>> project but this may be too ambitious.
>
> maybe possible with #2 above but definitely not with #1 ; but even if #2
> allows to do so ...
Just to check..

    #1 = project to resource mapping?
    #2 = extra project field?

Well, I sort of disagree :) Only in the sense that it would should 
require an extra bit of information for both (the ticket number 
associated with the project).
>
>> If we manage this, however, it should simplify the combining of multiple
>> existing environments into a single project from the user's perspective:
>> existing commit messages and internal ticket links within a project would
>> be able to remain consistent.
>>
>>
> ... maybe it's not a good idea considering your comment above . If ticket
> has its own identity (like it happens right now as opposite to project ID +
> ticket ID) references will always be valid (just like it happens right now)
> , no matter what relations it has with other resources (e.g. projects) and
> how they change with time . IMO going for #2 + independent ticket numbering
> may lead to over-complicating a system that just works right now . In any
> case that doesn't mean that visually e.g. project ID (e.g. short_name)
> might be displayed in ticket link text.
That is definitely a good argument and, for the initial work, it might 
be worth sticking to that. My reasoning was based on the idea of people 
wanting to combine existing environments. Existing references would 
become invalid if we were to expect to be able to do this.

While there is no route to import tickets or environments, we can defer 
a decision and see what others make of it.

Cheers,
     Gary


--------------070908020600040808060002--