RE: [Proposal] Core Bloodhound - basic concepts
Rather than Celery, I've had a lot of experience and success with Django Channels (websockets). See https://channels.readthedocs.io And my post here: https://stackoverflow.com/questions/42815835/how-to-make-webpage-to-show-real-time-values-sent-from-raspberry-pi/42817627#42817627 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. j. -Original Message- From: Allan Swanepoel [mailto:allanice...@gmail.com] Sent: 11 March 2018 21:36 To: dev@bloodhound.apache.org 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 https://djacket.github.io/ 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
Re: [Proposal] Migrate platform from Trac to Django
+1 on that proposal. I've done a lot of work in Django so will be happy to help On 13 December 2017 at 01:13, Gary wrote: > Hi everyone, > > I would like to propose that Apache Bloodhound should migrate away from > Trac as a base and instead use the Django web framework. > > Some of the advantages we would gain from such a move include: > > * Django supports Python 3 (as I understand it from version 2.0, Python > 2 support is dropped) > * Django is popular enough that it should be considered a good > transferable skill for our contributors > * Similarly it may be that potential contributors with Django > experience may be attracted to this project > > Other benefits we will have is that we will gain better control over the > basic data model rather than having to do any monkey patching or sql > translation. > > My proposal as it is does not intend to go any further than settle the > question of our desire to change from Trac to Django but there are > decisions around some of the practicalities that are worth considering. > > Given previous discussions, I suspect that we have enough support for > some kind of migration to Django as a base for the project. As far as I > am concerned there is nothing in previous discussions during the setup > of the Apache Bloodhound project that ties the community to Trac as a > base. Our only real commitment regarding our dealing with Trac was that > we would not encourage any kind of fork. Please do put me right if > anyone feels I am misrepresenting the situation of course. > > There are still a range of ways that we could implement such a migration > to Django, from starting from scratch to attempting to match the > interfaces provided by Trac so as to limit changes to code that sits on > top of it. > > The latter extreme does still feel a bit too much like forking Trac for > my liking so I think we need to be careful if something like that is > seen as best. > > To start from scratch will leave us with plenty to do but I am hoping > that we will find ways to integrate other external projects to provide > features, either through Django apps and middleware or beyond. > > Regardless of other decisions, the scope of the project should remain > broadly the same, so we would be aiming to have reasonable feature > parity including, amongst other stuff: > > * Multi tracker support (multi-product) > * Integrated wiki > * Fast search plugin > * SCM integration > > We will obviously also need to ensure that we can migrate from a > bloodhound based on Trac to any new version. > > I look forward to hearing thoughts around this. > > Cheers, > Gary > -- -- <http://www.pavegen.com> *Jason Morgan* Principal Engineer t: +44 1223 781555 m: +44 (0) 7877 662290 ddi: +44 1223 781556 *Engineering* Pavegen Systems Ltd Future Business Centre Kings Hedges Road Cambridge, CB4 2HY *Head Office* 5-15 Cromer St London, WC1H 8LS t: +44 (0) 2033 977 279 pavegen.com <http://www.pavegen.com> #thenextstep16 <http://www.pavegen.com/livestream> <http://www.twitter.com/pavegen> <http://www.facebook.com/pavegen> <https://www.linkedin.com/company/pavegen-system-ltd-> -- The content of this email and any attachments are confidential and may contain privileged information. If you are not the addressee it may be unlawful for you to read, copy, distribute, disclose or otherwise use the information contained herein. Company Registered no: 06980029 | Company VAT no: 996499723
Re: [Proposal] How to get out of this situation?
I would argue there is a more fundamental problem with this project. As a potential user, if you search for bug tracker you find Bloodhound, but it looks like a dead project. The project pages are mostly broken there have been no public releases in ages and there is little consistency in the user documentation with any current or planned releases. It looks like an abandoned project before you start. It has done for quite a few years. This is why there is little traction from both potential developers and users. I would propose a fork. Move it away from Apache. Create a new home page and new working dist with decent user documentation. Abandon all the WIP cruft. Start over. Create a new dev forum and start afresh with a new resolution and set of goals. Jason On 23 October 2017 at 08:23, Dammina Sahabandu wrote: > Hi Gary/All, > > Over the last couple of years we have been struggling with getting the > project out of this moving to attic situation. The main reason behind this > was our current members getting busy and couldn't find time to contribute > to the project. As a result of this, even though we get enough attention > from possible new contributors we were not capable of helping them enough > to get started. > > Gary has suggested few times that for a new contributor it might be hard to > get familiar with the code base. If that is the case why don't we point out > some small scale changes such as minor UI improvements to get them started. > Otherwise, even if we keep going like this for another few months > eventually the project will be moved to attic. > > Therefore, please contribute your ideas now before its too late. Lets give > it one more try to re-build the project and the community. > > Thanks, > Dammina > > -- > Dammina Sahabandu > Associate Tech Lead, AdroitLogic > Committer, Apache Software Foundation > AMIE (SL) > Bsc Eng Hons (Moratuwa) > +94716422775 > -- -- <http://www.pavegen.com> *Jason Morgan* Principal Engineer t: +44 1223 781555 m: +44 (0) 7877 662290 ddi: +44 1223 781556 *Engineering* Pavegen Systems Ltd Future Business Centre Kings Hedges Road Cambridge, CB4 2HY *Head Office* 5-15 Cromer St London, WC1H 8LS t: +44 (0) 2033 977 279 pavegen.com <http://www.pavegen.com> #thenextstep16 <http://www.pavegen.com/livestream> <http://www.twitter.com/pavegen> <http://www.facebook.com/pavegen> <https://www.linkedin.com/company/pavegen-system-ltd-> -- The content of this email and any attachments are confidential and may contain privileged information. If you are not the addressee it may be unlawful for you to read, copy, distribute, disclose or otherwise use the information contained herein. Company Registered no: 06980029 | Company VAT no: 996499723
Re: Public bloodhound down
Hi, It looks to me like somebody at Apache has removed the virtualhost for bloodhound. The root of this server seems to indicate this: https://issues.apache.org/ I have access to several VPS with decent internet connections which can host it if you can't get Apache to play ball and put it up again. Regards, Jason Morgan On 18 January 2017 at 02:02, Ryan J Ollos wrote: > On Mon, Jul 18, 2016 at 2:49 AM Tom Edwards wrote: > > > Hi, > > > > The public self-hosted instance of bloodhound here: > > > > https://issues.apache.org/bloodhound/wiki/BloodhoundInstall > > > > has been down for the last few days. As most of the documentation appears > > hosted through this portal, including contact information, I've only go > > this email address to report issues. > > > > Thanks, > > > > Tom > > > > It seems issues.apache.org/bloodhound is down again: "The requested URL > /bloodhound was not found on this server." > > I may have access to the vm, but I can't even remember anymore and don't > have time right now to go digging. Could someone with access please take a > look? > > - Ryan > -- -- <http://www.pavegen.com> *Jason Morgan* Principal Engineer t: +44 1223 781555 m: +44 (0) 7877 662290 ddi: +44 1223 781556 *Engineering* Pavegen Systems Ltd Future Business Centre Kings Hedges Road Cambridge, CB4 2HY *Head Office* 5-15 Cromer St London, WC1H 8LS t: +44 (0) 2033 977 279 pavegen.com <http://www.pavegen.com> #thenextstep16 <http://www.pavegen.com/livestream> <http://www.twitter.com/pavegen> <http://www.facebook.com/pavegen> <https://www.linkedin.com/company/pavegen-system-ltd-> -- The content of this email and any attachments are confidential and may contain privileged information. If you are not the addressee it may be unlawful for you to read, copy, distribute, disclose or otherwise use the information contained herein. Company Registered no: 06980029 | Company VAT no: 996499723
New install
Hi, Emailing the dev list rather than user list as it seems the user list has had just 4 emails in over a year so is probably dormant. I'm exicited to see that the activity on Bloodhound has picked up. This is encouraged me to install it here as it is clearly the most feature full bug tracking software other than JIRA, and for me being written in Python is a big advantage (I'm a big fan of the language) A couple issues, probably down to me not finding the correct documentation rather than actual bugs. Installation: The current tradition is to install non-packaged local deployments in /opt, however the instructions for installing Bloodhound want you to install it as a non-privileged user in ~ (tilde). This is OK (and preferred) for development but for a deployment not so. e.g. The distributed install instructions won't work as they are as they expect the logged in user to be called 'bloodhound' as this is the UID given for the WSGI app. 1: What would be the correct way to deploy Bloodhound? It seems to install in installer/bloodhound, surely this is not correct, am I doing this wrong or does the installer need some work? I notice that the install method creates many files with absolute paths built into them (pointing to paths owned by a real user and not Mr Bloodhound), we all know this is not good practice. Perhaps there should be an issue raised to fix this? Secondly: I'd like to use BH with SVN. I can't find any documentation for this. The SVN page in the settings wants an absolute path rather than a URL, does this mean that the SVN repos and BH must be on the same server (or NFS)? Luckily this is the case for us, but if I enter the SVN repos root path it then says I must run: trac-admin $ENV repository resync "serverside" serverside being the name of the repository. However it does not say where this should be run, what $ENV should be, it fails with Error: No Trac environment found at /opt/apache-bloodhound-0.8/installer/bloodhound/repository [Errno 2] No such file or directory: '/opt/apache-bloodhound-0.8/installer/bloodhound/repository/VERSION' what is it expecting to find in the non-existent directory repository? I used trac many, many years ago, but it's changed enough for me to not be at all familier with it's operation. Any help appreciated Regards, Jason
