It's a +1 for this proposal from me. I like the idea of a set of modules that can be run independently or together within the Django framework. Hopefully there will be more interest in taking part in the project as a result of this proposal.
I am looking forward to the discussions / working towards a release based on Django. Cheers, John. On 13 December 2017 at 07:07, Dammina Sahabandu <[email protected]> wrote: > Hi Gary, > > Thank you very much for pushing this effort. I agree with almost all the > facts that you have pointed out. I hope to get back with some more ideas > after doing some thorough research on the facts that you have already > noted. > > Thanks, > Dammina > > On Wed, Dec 13, 2017 at 6:43 AM, Gary <[email protected]> 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 > > > > > > -- > Dammina Sahabandu > PMC & Committer, Apache Software Foundation > AMIE (SL) > Bsc Eng Hons (Moratuwa) > +94716422775 >
