Hi Gary Thanks for the explanations. Makes sense. The django ecosystem could really add a lot of value around the actual issue tracking (authentication etc.). Plus it's a platform where a lot of people already are comfortable with.
But still, it's a totally different kind of challenge than just extending an existing and time-proven system like trac. Cheers Samuel 2017-11-10 15:39 GMT+01:00 Gary <[email protected]>: > 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 >
