On Tue, 7 Nov 2017, at 11:45 PM, Samuel Iseli wrote: > Hi there > > Thrilling to see things moving. > > I'm a long time trac user and was looking forward to bloodhound to become > a > trac with a better look and usability. > > I think the discussion here about basing bloodhound on trac or on django > / > flask misses an important point: > > trac is actually more than just a web development framework. it provides > quite a lot of features that bloodhound builds on. > the core issue-tracking is only one part. Things I quite like about trac > is > the tightly integrated wiki system and the various possibilities for > querying the issues data. > Agreed there is some cruft that comes with trac too... > Newly implementing some of these parts that make trac and bloodhound > great, > definitely means quite a lot of work. > > The main appeal of bloodhound to me was that it was built "on the > shoulders" of trac and didn't need to reimplement a lot of stuff that > trac > just has out of the box. It was a head start comparrf to starting an > issue > tracker from scratch. > The question is, are there enough people willing to spend their time for > a > complete new implementation of the x-th issue tracking system? > > I don't want to appear discouraging, I really like django and I would > certainly be happy if bloodhound evolved. > But the purpose of the bloodhound project would change quite radically > from > bringing a better UI to trac to building a new issue tracking system from > scratch. > If the separation from trac really pushes the project forward then this > would be great! Perhaps whilst keeping some of the "spirit" of trac. > > Cheers > Samuel
Hi Samuel, Thank you for the encouragement. Obviously you are correct that Trac gave us a base that was more than just a web framework and I can certainly agree that there is a lot to Trac that I like. Integrating wiki and issues still remains a good idea for instance. Extensions from trac-hacks is also attractive. However, for us to maintain a developer community, there has to be a strong enough desire to continue the work and enough attractiveness about the approach to be encouraging for newcomers to consider becoming contributors and make it on to the PMC. Linking the purpose of the bloodhound project to trac as you suggest is understandable. We have proudly stated that as the heritage but ultimately I hope that it is understood that we want to create a great open source issue tracker. The official short description of the project is "Apache Bloodhound is a software development collaboration tool, including issue tracking, wiki and repository browsing" (see https://projects.apache.org/project.html?bloodhound for instance.) While there is nothing specifically to stop the community taking it in a different direction, I suspect that fits reasonably within your hope to keep with the spirit of Trac. For myself, I would like to see that we maintain wide support for different VCS options, maintaining a wiki style for tickets in a similar way, inclusion of a wiki and a good query system is always going to be useful. The other things we were meant to add to Trac were easy installation, multi product (or multi project if you prefer) support and inclusion of some other pieces to improve usability. What I hope we can gain from changing to using a popular web framework like Flask or Django would be that we gain control over the main part of the structure of the issue tracker and look at improving on our solutions for multi product for instance. One thing that Trac seems to lack, at least up to the versions I have looked at, was a full featured account system which is why we included a package from trac-hacks for this purpose. The hope in changing to a different web framework is that we will be able to make use of another rich ecosystem. I suspect that Django in particular could be a good choice and it may be that with careful structuring of our project we could provide services to other apps. Another aspect of the structure I would like to see changes to is ensuring that we expose what functionality we can with a RESTful interface. Though it may sound like overkill, I would like to have the flexibility of choice for the user interface and building this from scratch will enable other interesting interactions with the system that users could benefit from. I think I have said enough for now though I feel there is plenty more to be said. Anyway, please keep up the discussion! Cheers, Gary
