Hi Gary, Another plus one on this!
> 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. One point to note about Django is it's really good for transitioning from existing datamodels. See https://docs.djangoproject.com/en/2.0/howto/legacy-databases/ What can work well is having a hybrid situation of existing code + Django looking at same database tables while bringing things up to par with the existing functionality. This is kind of like a double heart bypass approach. Auto-generate models from existing tables. Models are 'unmanaged' in first instance. Then build rest of Django (views, forms etc.) around the models. Then excise old Bloodhound / Trac code when things are up to scratch. The make models managed plus migrations. Then data model can evolve independently from that point forward. Nice point is it give an opportunity to keep existing data. May be more hassle than it's worth but just thought I'd throw it in the mix. Thanks, Daniel On 13/12/17 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
