You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Jure Zitnik <ju...@digiverse.si> on 2012/11/07 08:42:55 UTC
Multi product enhancements
Hi all,
I was looking into enhancing multi product support within Bloodhound.
afaik current multi product support consists of the ability to
define/administer product(s) and the ability to assign product to a
ticket. What I was thinking of starting with are the following rather
simple features/functionalities:
1. product/ticket namespaces - product and ticket ID would form a two
dimensional namespace, tickets would in addition to current URL scheme
also be addressable through the product URL namespace, namely
/ticket/<product>/<id>. Each product would have a separate numberspace
for product ticket IDs. The same might also be applied for wikis, not
sure about whether it's something that would come handy or not.
2. tickets should be moveable between products, old ticket product IDs
(and URLs) should be remembered, making the same ticket accessible
through old products namespaces.
3. enhance query to limit the search to specific product
Down the line it'd be really useful to have per product permissions,
versions, milestones, components, ticket lifecycles, predefined queries,
etc., which is a bit more complex part that should be discussed in a
separate thread.
Any comments/suggestions on this?
Cheers,
Jure
Re: Multi product enhancements
Posted by Olemis Lang <ol...@gmail.com>.
On 11/7/12, Ryan Ollos <ry...@wandisco.com> wrote:
> On Wed, Nov 7, 2012 at 8:01 PM, Olemis Lang <ol...@gmail.com> wrote:
>
>> [...]
>> I'll spend some time reading the whole thread . Nonetheless in advance
>> I suggest to summarize this discussion in the form of a wiki page we
>> all can edit , and discuss each change @ bh-dev . Fact is that often
>> it's hard to know what's the actual shape of some feature by reading
>> discussions taking place at the ML ... that's what the wiki page is
>> for .
>>
>
> +1 for summarizing on wiki pages. I'll plan to do the same for the Ticket
> Relations feature if others agree.
>
fwiw , move on ... ;)
> I favor organizing the pages in a hierarchy, as is done on t.e.o (1). The
> top level wiki page could be named something like DevProposals or
> FeatureProposals.
>
... or Brainstorming , Labs , ... whatever ;)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: Multi product enhancements
Posted by Ryan Ollos <ry...@wandisco.com>.
On Wed, Nov 7, 2012 at 8:01 PM, Olemis Lang <ol...@gmail.com> wrote:
> [...]
> I'll spend some time reading the whole thread . Nonetheless in advance
> I suggest to summarize this discussion in the form of a wiki page we
> all can edit , and discuss each change @ bh-dev . Fact is that often
> it's hard to know what's the actual shape of some feature by reading
> discussions taking place at the ML ... that's what the wiki page is
> for .
>
+1 for summarizing on wiki pages. I'll plan to do the same for the Ticket
Relations feature if others agree.
I favor organizing the pages in a hierarchy, as is done on t.e.o (1). The
top level wiki page could be named something like DevProposals or
FeatureProposals.
(1) http://trac.edgewall.org/wiki/TracDev/Proposals
Re: Multi product enhancements
Posted by Olemis Lang <ol...@gmail.com>.
On 11/7/12, Jure Zitnik <ju...@digiverse.si> wrote:
> Hi all,
>
:)
> I was looking into enhancing multi product support within Bloodhound.
> afaik current multi product support consists of the ability to
> define/administer product(s) and the ability to assign product to a
> ticket. What I was thinking of starting with are the following rather
> simple features/functionalities:
>
I'll spend some time reading the whole thread . Nonetheless in advance
I suggest to summarize this discussion in the form of a wiki page we
all can edit , and discuss each change @ bh-dev . Fact is that often
it's hard to know what's the actual shape of some feature by reading
discussions taking place at the ML ... that's what the wiki page is
for .
my $0.02
;)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: Multi product enhancements
Posted by Ljupčo Taseski <tl...@digiverse.si>.
On 7 November 2012 10:29, Branko Čibej <br...@wandisco.com> wrote:
> Another question that popped up was how to maintain eternal historical
> uniqueness of ticket IDs when a tag for a previously deleted product
> gets reused. One option is to never allow reusing historically used tags
> in new products, but that seems a bit too restrictive. We came up with
> this:
>
> * along with the tag+number history for each ticket, remember the
> maximum ticket number per tag
> * when a tag gets reused, issue new ticket numbers from that
> remembered value, not from 1
>
>From user's POV, I'm not convinced, I'll be happy with a new project
starting with, let's say, 13678...
It is true, that immutable tags would greatly reduce the availability of
"nice" tags (given enough time), but this is an only a real problem for a
public repository that hosts 100s/1000s of projects.
Ljupco
Re: Multi product enhancements
Posted by Peter Koželj <pe...@digiverse.si>.
Agree, if we are doing product namespace, we should do it properly :)
On 15 November 2012 16:24, Gary Martin <ga...@wandisco.com> wrote:
> On 15/11/12 11:48, Branko Čibej wrote:
>
>> On 14.11.2012 12:36, Gary Martin wrote:
>>
>>> On 14/11/12 08:38, Olemis Lang wrote:
>>>
>>>> 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.
>>>
>> I'll presume to barge in with the opinion that this is not something you
>> can add "maybe later" in a backward-compatible way, unless you plan to
>> renumber all tickets in existing databases ... which would certainly get
>> Bloodhound mentioned on /. but not in a nice way. :)
>>
>> -- Brane
>>
>>
> Absolutely. For backwards compatibility we could maintain any gaps in the
> numbering but I don't think that is particularly satisfying solution. There
> appear to be a number of good reasons to allow for continuous numbering
> within a product once you take potential imports into account. Has anyone
> got any compelling arguments for why we should not take this approach?
>
> Cheers,
> Gary
>
Re: Multi product enhancements
Posted by Gary Martin <ga...@wandisco.com>.
On 15/11/12 11:48, Branko Čibej wrote:
> On 14.11.2012 12:36, Gary Martin wrote:
>> On 14/11/12 08:38, Olemis Lang wrote:
>>> 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.
> I'll presume to barge in with the opinion that this is not something you
> can add "maybe later" in a backward-compatible way, unless you plan to
> renumber all tickets in existing databases ... which would certainly get
> Bloodhound mentioned on /. but not in a nice way. :)
>
> -- Brane
>
Absolutely. For backwards compatibility we could maintain any gaps in
the numbering but I don't think that is particularly satisfying
solution. There appear to be a number of good reasons to allow for
continuous numbering within a product once you take potential imports
into account. Has anyone got any compelling arguments for why we should
not take this approach?
Cheers,
Gary
Re: Multi product enhancements
Posted by Branko Čibej <br...@wandisco.com>.
On 14.11.2012 12:36, Gary Martin wrote:
> On 14/11/12 08:38, Olemis Lang wrote:
>>
>> 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.
I'll presume to barge in with the opinion that this is not something you
can add "maybe later" in a backward-compatible way, unless you plan to
renumber all tickets in existing databases ... which would certainly get
Bloodhound mentioned on /. but not in a nice way. :)
-- Brane
Re: Multi product enhancements
Posted by Gary Martin <ga...@wandisco.com>.
On 14/11/12 08:38, Olemis Lang wrote:
> On 11/13/12, Jure Zitnik <ju...@digiverse.si> wrote:
>> On 11/7/12 9:58 PM, Gary Martin wrote:
>>> On 7 November 2012 09:29, Branko Čibej <br...@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
Re: Multi product enhancements
Posted by Peter Koželj <pe...@digiverse.si>.
On 14 November 2012 09:38, Olemis Lang <ol...@gmail.com> wrote:
> On 11/13/12, Jure Zitnik <ju...@digiverse.si> wrote:
> > On 11/7/12 9:58 PM, Gary Martin wrote:
> >> On 7 November 2012 09:29, Branko Čibej <br...@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
>
I am not particularly keen on true product number-space, but there is at
least one very compelling reason to have at least limited support for this.
Migrating from systems like Jira almost demands this. If I had a large Jira
database, keeping the ticket id's during migration to BH would most
certainly be a requirement.
This could also be achieved with something like aliases that can act
independently from products but at that point I think I prefer a single
solution in the form of true product ticket number-space.
>
> >
> > 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 ...
> >
>
> 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
> )
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
Re: Multi product enhancements
Posted by Olemis Lang <ol...@gmail.com>.
On 11/13/12, Jure Zitnik <ju...@digiverse.si> wrote:
> On 11/7/12 9:58 PM, Gary Martin wrote:
>> On 7 November 2012 09:29, Branko Čibej <br...@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
>
> 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 ...
>
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)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: Multi product enhancements
Posted by Jure Zitnik <ju...@digiverse.si>.
On 11/7/12 9:58 PM, Gary Martin wrote:
> On 7 November 2012 09:29, Branko Čibej <br...@wandisco.com> wrote:
>
>> On 07.11.2012 08:42, Jure Zitnik wrote:
>>> Hi all,
>>>
>>> I was looking into enhancing multi product support within Bloodhound.
>>> afaik current multi product support consists of the ability to
>>> define/administer product(s) and the ability to assign product to a
>>> ticket. What I was thinking of starting with are the following rather
>>> simple features/functionalities:
>>>
>>> 1. product/ticket namespaces - product and ticket ID would form a two
>>> dimensional namespace, tickets would in addition to current URL scheme
>>> also be addressable through the product URL namespace, namely
>>> /ticket/<product>/<id>. Each product would have a separate numberspace
>>> for product ticket IDs. The same might also be applied for wikis, not
>>> sure about whether it's something that would come handy or not.
>>>
>>> 2. tickets should be moveable between products, old ticket product IDs
>>> (and URLs) should be remembered, making the same ticket accessible
>>> through old products namespaces.
>>>
>>> 3. enhance query to limit the search to specific product
>>>
>>> Down the line it'd be really useful to have per product permissions,
>>> versions, milestones, components, ticket lifecycles, predefined
>>> queries, etc., which is a bit more complex part that should be
>>> discussed in a separate thread.
>>>
>>> Any comments/suggestions on this?
> I think that this is broadly in line with what we want. I may comment more
> in the future on this. But for now, I will just say that I see no reason
> why the wiki should be restricted from being contained within a product.
>
>
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, such as ticket sequence in that
namespace. As a consequence of that, ticket create would result in two
table inserts, one for the ticket and one for the product namespace table.
To keep the database consistency, the two inserts should happen within
the same transaction. Ticket insert happens within a database
transaction rather deep in the trac core (trac/ticket/model.py). Looking
at the TransactionContextManager, it should be possible to create a
database transaction higher on the stack that would eventually get
reused in the trac core ticket insert. Higher in the stack in this case
would mean to override the _do_create and _do_save from the trac
TicketModule (as this is what ProductTicketModule derives from) - this
is where ticket gets created/updated and notifications get sent out.
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 ...
Any opinions on what is the best approach to address this? Do we have
sort of a 'strategy' on how to address issues like this - modified
functionality that can't be implemented using extension points or by
classical derive-override-call parent approach? 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.
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.
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.
Cheers,
Jure
Re: Multi product enhancements
Posted by Gary Martin <ga...@wandisco.com>.
On 7 November 2012 09:29, Branko Čibej <br...@wandisco.com> wrote:
> On 07.11.2012 08:42, Jure Zitnik wrote:
> > Hi all,
> >
> > I was looking into enhancing multi product support within Bloodhound.
> > afaik current multi product support consists of the ability to
> > define/administer product(s) and the ability to assign product to a
> > ticket. What I was thinking of starting with are the following rather
> > simple features/functionalities:
> >
> > 1. product/ticket namespaces - product and ticket ID would form a two
> > dimensional namespace, tickets would in addition to current URL scheme
> > also be addressable through the product URL namespace, namely
> > /ticket/<product>/<id>. Each product would have a separate numberspace
> > for product ticket IDs. The same might also be applied for wikis, not
> > sure about whether it's something that would come handy or not.
> >
> > 2. tickets should be moveable between products, old ticket product IDs
> > (and URLs) should be remembered, making the same ticket accessible
> > through old products namespaces.
> >
> > 3. enhance query to limit the search to specific product
> >
> > Down the line it'd be really useful to have per product permissions,
> > versions, milestones, components, ticket lifecycles, predefined
> > queries, etc., which is a bit more complex part that should be
> > discussed in a separate thread.
> >
> > Any comments/suggestions on this?
>
I think that this is broadly in line with what we want. I may comment more
in the future on this. But for now, I will just say that I see no reason
why the wiki should be restricted from being contained within a product.
> Gary and I talked about this the a couple days ago at ApacheCon;
> specifically, about whether the product tag (as opposed to the product
> name) should be immutable or not.
>
> The assumption is that a "product" has two attributes:
>
> name: used for user-friendly display
> tag: shorter string, constrained syntax, unique
>
> So, you could have a product named "Finnegan's Wake" with tag FW, and
> ticket IDs within that product would have the format FW-123. Later on
> you realize that your product is about the book, not the ballad, and you
> rename it to "Finnegans Wake".
>
> The some twit comes along and wants to change the tag to FWJOYCE. There
> are conceptually two ways to do that:
>
> * Keep tags immutable, "rename" it by creating a new product, move all
> tickets to it and delete the new product.
> * Actually allow renaming the tag; a tag rename would still have to
> maintain the ticket ID history.
>
> We came to the conclusion that it's best to keep tags immutable.
> Eventually one could add a tag-rename helper to the UI that would do the
> new-product/move-tickets/delete-old-product dance.
>
I'm not sure whether we had subtly different points of view here. On this
point I was basically thinking that we should avoid making it easy by
default for now, in order to discourage renaming. As Brane suggests, it can
be considered a silly thing to want to do. Although a prefix will probably
initially be chosen as a shortening of the project name, there is no
specific need for this to be the case. Current users of the system will be
used to the original prefix and new users shouldn't find it a particular
problem.
All this should be interpreted as me suggesting that, unless there are
compelling reasons to expose a method to help with the new-move-delete
product process to users, it would be better to wait for the demand.
> Another question that popped up was how to maintain eternal historical
> uniqueness of ticket IDs when a tag for a previously deleted product
> gets reused. One option is to never allow reusing historically used tags
> in new products, but that seems a bit too restrictive. We came up with
> this:
>
> * along with the tag+number history for each ticket, remember the
> maximum ticket number per tag
> * when a tag gets reused, issue new ticket numbers from that
> remembered value, not from 1
> * this includes renumbering tickets that already have an ID with the
> reused tag, because it's never clear that the resurrected tag is
> used for the same product as before.
> o this might imply remembering the product name associated with a
> range of ticket numbers within a tag
>
Yes, I almost forgot about that part of the conversation. I don't have a
particular problem with disallowing use of old product prefixes actually.
Given that we will be maintaining old links, it would be a bit strange when
the meaning of the namespace changes at a given number. The best excuse for
allowing use is actually that the project returns to its original prefix -
however confusing that is.
There is, of course, another way to look at this. Sorry if anyone else has
already pointed this out but we could just maintain the old prefixes as
synonyms for the current product prefix. The main problem with this would
be that it could encourage people to continue using an old prefix whilst
some colleagues use the new one and potentially could cause more confusion.
Anyway, the discontinuity in numbering is not completely anathema to me but
losing the ability to use a specific prefix is not really the biggest of
problems.
Cheers,
Gary
Re: Multi product enhancements
Posted by Branko Čibej <br...@wandisco.com>.
On 07.11.2012 10:29, Branko Čibej wrote:
> Another question that popped up was how to maintain eternal historical
> uniqueness of ticket IDs when a tag for a previously deleted product
> gets reused. One option is to never allow reusing historically used tags
> in new products, but that seems a bit too restrictive. We came up with this:
>
> * along with the tag+number history for each ticket, remember the
> maximum ticket number per tag
> * when a tag gets reused, issue new ticket numbers from that
> remembered value, not from 1
> * this includes renumbering tickets that already have an ID with the
> reused tag, because it's never clear that the resurrected tag is
> used for the same product as before.
> o this might imply remembering the product name associated with a
> range of ticket numbers within a tag
A nice property of the above is that, on the web UI side, you can just
issue permanent redirects from old ticket URLs to whatever the current
ticket URL is.
-- Brane
Re: Multi product enhancements
Posted by Branko Čibej <br...@wandisco.com>.
On 07.11.2012 08:42, Jure Zitnik wrote:
> Hi all,
>
> I was looking into enhancing multi product support within Bloodhound.
> afaik current multi product support consists of the ability to
> define/administer product(s) and the ability to assign product to a
> ticket. What I was thinking of starting with are the following rather
> simple features/functionalities:
>
> 1. product/ticket namespaces - product and ticket ID would form a two
> dimensional namespace, tickets would in addition to current URL scheme
> also be addressable through the product URL namespace, namely
> /ticket/<product>/<id>. Each product would have a separate numberspace
> for product ticket IDs. The same might also be applied for wikis, not
> sure about whether it's something that would come handy or not.
>
> 2. tickets should be moveable between products, old ticket product IDs
> (and URLs) should be remembered, making the same ticket accessible
> through old products namespaces.
>
> 3. enhance query to limit the search to specific product
>
> Down the line it'd be really useful to have per product permissions,
> versions, milestones, components, ticket lifecycles, predefined
> queries, etc., which is a bit more complex part that should be
> discussed in a separate thread.
>
> Any comments/suggestions on this?
Gary and I talked about this the a couple days ago at ApacheCon;
specifically, about whether the product tag (as opposed to the product
name) should be immutable or not.
The assumption is that a "product" has two attributes:
name: used for user-friendly display
tag: shorter string, constrained syntax, unique
So, you could have a product named "Finnegan's Wake" with tag FW, and
ticket IDs within that product would have the format FW-123. Later on
you realize that your product is about the book, not the ballad, and you
rename it to "Finnegans Wake".
The some twit comes along and wants to change the tag to FWJOYCE. There
are conceptually two ways to do that:
* Keep tags immutable, "rename" it by creating a new product, move all
tickets to it and delete the new product.
* Actually allow renaming the tag; a tag rename would still have to
maintain the ticket ID history.
We came to the conclusion that it's best to keep tags immutable.
Eventually one could add a tag-rename helper to the UI that would do the
new-product/move-tickets/delete-old-product dance.
Another question that popped up was how to maintain eternal historical
uniqueness of ticket IDs when a tag for a previously deleted product
gets reused. One option is to never allow reusing historically used tags
in new products, but that seems a bit too restrictive. We came up with this:
* along with the tag+number history for each ticket, remember the
maximum ticket number per tag
* when a tag gets reused, issue new ticket numbers from that
remembered value, not from 1
* this includes renumbering tickets that already have an ID with the
reused tag, because it's never clear that the resurrected tag is
used for the same product as before.
o this might imply remembering the product name associated with a
range of ticket numbers within a tag
-- Brane
Re: Multi product enhancements
Posted by Olemis Lang <ol...@gmail.com>.
On 11/7/12, Jure Zitnik <ju...@digiverse.si> wrote:
> Hi all,
>
:)
> I was looking into enhancing multi product support within Bloodhound.
> afaik current multi product support consists of the ability to
> define/administer product(s) and the ability to assign product to a
> ticket. What I was thinking of starting with are the following rather
> simple features/functionalities:
>
> 1. product/ticket namespaces - product and ticket ID would form a two
> dimensional namespace, tickets would in addition to current URL scheme
> also be addressable through the product URL namespace, namely
> /ticket/<product>/<id>. Each product would have a separate numberspace
> for product ticket IDs. The same might also be applied for wikis, not
> sure about whether it's something that would come handy or not.
>
In first place , after reading only this part I'll start by saying
that we better pay attention to the big picture since the beginning .
Whatever we come up with has to deal with the fact that multi-product
support is not limited to the immediate need of getting things done
for tickets, wiki , ... and other resources in default Trac
installation . It's also about plugins . Once core resources will be
supported then there will be a need to have per-product code reviews ,
whiteboards , configuration , enabled/disabled components , blogs ,
test cases , pastebins , ... Besides in practice there will be many
possible URL mappings . I mention some examples below , but there may
be more :
1. http://server.com/path/to/bh/products/<product>/ticket/<id> ...
as it stands nowadays
2. http://<product>.server.com/ticket/<id> ... i.e. something like
e.g. t.e.o and
sibling projects
3. http://<product>.server.com/path/to/bh/ticket/<id> ...
consider Allura @ sf.net as an example ;)
> 2. tickets should be moveable between products, old ticket product IDs
> (and URLs) should be remembered, making the same ticket accessible
> through old products namespaces.
>
IMO tickets should still have a unique ID . Hence there should be no
problem with moving them between products . History of previous
products will be recorded in ticket change log . In case of mismatch
e.g. considering URL mapping (2) above on accessing
http://<wrong_product>.server.com/ticket/<id> I suggest to include an
informative message of the form
<p>This ticket does not belong in this product . <a
href="http://<product>.server.com/ticket/<id>">Click here</a> to see
it .</p>
> 3. enhance query to limit the search to specific product
>
Yes, it'd be nice to have some of those ;)
> Down the line it'd be really useful to have per product permissions,
> versions, milestones, components, ticket lifecycles, predefined queries,
> etc., which is a bit more complex part that should be discussed in a
> separate thread.
>
Product-specific permissions , workflow , configuration , ... there
should be a way to get them done , yes .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article: