bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Morgan" <>
Subject RE: [Proposal] Core Bloodhound - basic concepts
Date Mon, 12 Mar 2018 12:10:47 GMT
Rather than Celery, I've had a lot of experience and success with Django Channels (websockets).

And my post here:

Websockets are supported natively by all modern browsers so it makes a very portable solution
with a low client overhead and with Channels, all the benefits of Django.


-----Original Message-----
From: Allan Swanepoel [] 
Sent: 11 March 2018 21:36
Subject: Re: [Proposal] Core Bloodhound - basic concepts

Possibly take a look at what has already been done using Django in this arena?
 One project that jumps out with some Google foo is

Also, if you want to separate (loosely couple) the front-end and the back-end, possibly build
the whole front-end with some js framework like react?
All the functionality would be provided by the api, and all you need is some Ajax calls.

For the slow stuff, possibly make these more asynchronous and use some form of scheduler (celery
/ ampq bus)  to offload the work. Again, the result is posted back via the api.

Just my 2c's worth

On 11 Mar 2018 23:21, "Gary" <> wrote:

> Hi everyone,
> Sorry it has taken so long to get this written. With the understanding 
> that we have expressed the desire to move away from Trac as the base 
> for the project,  I'd like to put forward the following as an initial 
> proposal for the way we progress. You should not expect that this is 
> high on details. I only intend to provide some guidance around the 
> concepts that I would like to see used. I am hoping that this will be 
> enough to get a reasonable idea of what the core model might look like.
> In broad terms I am proposing that we
> * take the opportunity to design the project from the ground up as 
> opposed to attempting to build up the existing interfaces
> * build the project using the Django web framework
> * separate out a core sub-project with a well defined REST api for a 
> frontend UI sub-project to build upon
> The rest of this proposal sets out to define parts of the core sub-project.
> The core should provide enough services to support the main part of a 
> issue tracking UI. I am also expecting there to be further 
> sub-projects to support additional optional functionality.
> The core sub-project will probably provide a basic UI to make progress 
> ahead of work on the UI sub-project. I am not looking to define the UI 
> sub-project any further in this proposal although it is likely that it 
> will be highly dynamic, perhaps making use of websockets. The basic UI 
> of the core project should remain well-maintained throughout the life 
> of the project but at the moment my expectation would be that it is a 
> no-thrills interface.
> Back to the core sub-project, I am looking for this to be built on the 
> following concepts:
>  #0 a change in nomenclature from product to tracker as the top level
>  #1 uuids for pretty much everything
>  #2 tickets as the accumulation of ticket change events
>  #3 'labels' and 'label types' as a unifying concept for 
> categorisation of tickets
> One of the early decisions made in handling of multiple projects in 
> bloodhound was to call this feature multi-product. The reasoning for 
> this was that the term 'project' is overloaded (if I recall, there may 
> have been an excuse to add projects as a layer in bloodhound that 
> could be used to group tickets across products.) I would like to see 
> the basic functionality brought in to handle the ability to host 
> multiple projects (in the top level organisation sense) but change the 
> nomenclature to tracker to be as generic as possible. To be fair, the 
> name of the feature may not matter so much as I would also like to see 
> users given the ability to define their levels of organisation to a 
> greater extent. More on this in the discussion of #3.
> Note that I will use the term tracker in the rest of this proposal 
> where you might prefer to see product or project.
> The idea behind #1, uuids, is that it may be useful to be able to 
> unambiguously identify instances of objects even across bloodhound 
> instances. Pending decisions on how tickets are referenced, these 
> uuids could be used as a reference that is unchanging as it moved 
> between trackers.
> How tickets are stored as a whole is also worth tackling, which is 
> what #2 is trying to broadly decide. Here I am suggesting that the 
> state of a ticket can be built up from a query that collects all the 
> change events and applies the deltas in order. This could prove to be 
> a slow process so at some point we may want to look at keeping a 
> record of the current state or a checkpoint but, given that ticket 
> views are expected to show the history, these are details that are 
> required anyway. I suggest that we can look at optimising for speed 
> later. Knowing that we can update a ticket from deltas may be useful.
> Finally, I am suggesting in #3 that as much as possible we generalise 
> ticket categorisation. Categorisation is a central concept to capture 
> and, in trac we inherited categorisations such as statuses (open, in 
> progress, etc), types (bug, enhancement, task, etc), milestones, 
> versions, etc, and these had separate implementations. What I would 
> like to see is that, while we might provide an initial set of ways to 
> categorise tickets, we should allow users to add the categorisations 
> that they require. I'm suggesting calling this generalisation 'labels' 
> and 'label types' (though we can bikeshed that if we like!)
> There are a few ways to look at implementing labels as we could look 
> to capture a set of common kinds of collections so that there are 
> types of 'label types', as it were. What I mean by this is that you 
> can have labels that are simply a tag, perhaps some types of labels 
> should have descriptions, some might have dates associated with them. 
> Beyond that we would need to know where a label can be allowed to 
> coexist on a ticket with others of the same 'label type'. A lot of 
> these aspects could influence how you might want to display them.
> At the moment I believe that we can probably get away with a common 
> model across all label types and we can provide users with the tools 
> to define what you can do with labels of a given label type via the 
> properties of that label type.
> As you can see I have a lot to say about these labels. Another thing 
> that could be useful would be to be able to have label types and 
> labels that are available to a specific tracker, globally or even to a 
> set of trackers. To deliver this, label types and labels need to be 
> able to be associated with a variable number of trackers.
> We also need to be able to define workflows in terms of transitions 
> between labels and potentially how they are affected by other labels. 
> I think it is suffice to say that I would like to see an 
> implementation where users are able to define workflow transitions 
> with a great deal of flexibility in the label types that are involved.
> From the point of view of the transition from the trac model to the 
> desired model, we can attempt to make use of Django's migrations from 
> autogenerated models as brought to our attention by Daniel Brownridge. 
> I do want to ensure that there is a viable migration path in place 
> from the old bloodhound to the new.
> I think this is about as far as I want the proposal to go for now.
> Obviously there is going to be plenty more to decide.
> Please let me know your thoughts.
> Cheers,
>     Gary

View raw message